22:56 @thinca さんからの指摘を追記 @yuroyoro あとお節介ですが、n個前とdiffなら HEAD^ より HEAD~ の方がいいと思いますよ。両者では若干意味が違います。~なら HEAD~3 と数字が書けるのも利点です。あと個人的にはwhatchangedよりlog --statの方が見やすくて好きです。 2010-10-08 22:30:52 via Tween to @yuroyoro @yuroyoro URL このgitconfigの記事に関して質問なのですが、core.excludesfile は $HOME で動きますか?以前試した時ダメで、~/ なら動いたのでこちらを使ってるんですが。 2010-10-08 22:20:49 via Tween to @yuroyoro 「そんな.gitconfigで大丈夫か?」 そんなわけで、仕事でもモリンモリンにgi
最近、開発環境のテンプレート構築をしているのですが、「git commit するまえに考えるべき10のこと | Act as Professional – hiroki.jp by HIROCASTER」みたいに、ソースコードのバージョン管理を実際に始めるときに理解しておかないといけないことは、結構あるはずです。 それで、ソースコードのバージョン管理については、git commitするときに記録するコメントについて、いろいろと考えることもあります。Git Styleは「git/Documentation/SubmittingPatches at master · gitster/git · GitHub」にありますから、こういうのも参考になります。 英語で記述 一文の場合、文末にピリオドを付けない 主語は省く 時制は現在形 文頭の英単語は大文字 他にもないかなぁ、と探してみたら「Chang
gitのログを確認するのにtigをちょいちょい使ってますが、いまいち機能を使いこなせてない気がしたので改めてググったりしました。 インストール Mac, homebrewでのインストールはこれで。 % brew install tig キー操作 (今回調べて知ったことだけ) ・2ペイン時にフォーカスを移動する: Tab (毎回qで閉じてたや) ・検索: / (検索できたのね、、) iTerm2 + zsh + tmux + vim で快適な256色ターミナル環境を構築する - ( ꒪⌓꒪) ゆるよろ日記 によると、「'G'でgit gcが走ってしまって色々と取り返しがつかないことになる」そうなので以下を ~/.gitconfig に書き足しておく。 [tig "bind"] generic = g move-first-line generic = G move-last-line 便
‐ programming, open source, os, and a handful of tips 時間ができたのでHandBrake 0.9.5の日本語化に着手しているのだが、うっかり0.9.4のブランチで作業してしまったあげく、SourceForge.JP上のリポジトリにpushしてしまい途方に暮れる。 まあこういうミスをやる人は少ないだろうが、何かのヒントになるかもしれないので対処法をメモしておく。まず、「git log」コマンドで巻き戻したいcommitのハッシュを調べる。 $ git log : : commit 1485a5a2bbbb43eedbe131c919b7d604bcbd506d Author: unknown <hirom@.(none)> Date: Tue Jan 5 19:19:44 2010 +0900 update Installer, chan
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
こんばんは。今回、gitを使ってPhotoshopで扱うPSDファイルの変更を自動的にステージング・コミットし、バージョン管理を行えるスクリプト「psdwatcher」を開発しました。 発端 発端は僕のfacebookのつぶやきからでした。 このつぶやきに、ある方が返信をくれまして、その会話の中で「psdファイルをgitで管理する」というアイデアが思い浮かびました。 これですね。 このアイデアが浮かんでから、約3日くらいでpsdwatcherのベータ版を作成しました。 そして、コマンドオプションの動作やCPUの負荷などを総合考慮して、昨日正式にpsdwatcherをリリースしました。 Open Source alice1017/psdwatcher - You can watch the change log of psd file using git. インストール インストールは、ロー
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request(プルリクエスト)機能を使ったことはありますか? GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork(コピー)してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト
今日は、Git で複数人作業を行う際に共有リポジトリから pull する際の rebase オプションの必要性について検討してみました。 タイトルで結果は想像つくような気がしますが、順を追ってみましょう。 git pull でやってること merge と rebase git pull と git pull --rebase まとめ 1. git pull でやってること git pull コマンドは、fetch, merge をまとめて実行しています。 つまり、リモートブランチの最新のコミット情報をローカルトラッキングブランチへ持ってきて(fetch)、持ってきた最新のコミット情報とローカルブランチをマージ(merge)します。 参考:3.5 Git のブランチ機能 - リモートブランチ 2. merge と rebase ブランチを統合するには、マージの他にリベースがあります。 mer
gitを使って開発しているときに、以前のコミットのハッシュを直接指定してブランチを切らずにcheckoutすると(no branch)という無名のブランチができます。 どうしてそんなことをするかというと、例えば、開発を進めてる途中で別のやり方を思いついて以前の状態からやり直したいけど、あんまり自信ないからbranch切って名前つけるのはめんどくさい、みたいなときとか。 まあブランチきればすむ話ですが、とにかくno branchで作業しちゃうときもあるのです。そういうときに限ってうまく実装できて、no branchで作業していることを忘れてそのままcommitしてしまったりします。 で、なにげなくmasterに戻ってみるとさっきの作業内容が見えなくなって焦るわけです。 そういうときはno branchでコミットしたときのハッシュ値を直接指定してやればno branchでの状態に戻れます。no
公開日時: 2012-06-22 18:00 gitを使って何かする際、多くの場合は、既に誰かがどこかのサーバーに用意したプロジェクトのgitリポジトリをローカルにcloneして作業します。 一方、何か新しいプロジェクトを作成する場合は、そのプロジェクトを継続的に開発するかどうか分からないこともあり、先ず自分の手元でしばらく開発し、価値があると思った場合に限り、リモートのgitリポジトリを作成する場合もあります。 そこで、ひとまずローカルに作成したgitリポジトリに対し、後からリモートのリポジトリを作成する方法をまとめます。 まず、ローカルでリポジトリを作成します。 ここでのプロジェクト名は「project」とします。 mkdir project cd project git init emacs readme.txt git add readme.txt git commit -m 'i
はじめに ※ 以前git rebase -i して何か失敗して痛い目にあったりした ※ これ。git rebase master に失敗した模様のとき【git】 ※ でも最近ちゃんとgitを理解し出したので再挑戦したらgit rebase -i がやっぱりイケてる 前提 ※ .zshrc (.bash_profile?) にて、gitのデフォルトエディタを設定しときます .zshrc export GIT_EDITOR=vim ※ あと、念のためローカルbranchは新しく切って試します % git branch * develop master % git branch rebase_test % git branch rebase_test * develop master % git checkout rebase_test ※ ぜんぜん関係無いけど、tigあるとちょっと幸せかも そ
git にはコミットした内容を取り消す方法がいくつかありますが、いったんリリースしたコンテンツの公開期間が終了してその内容を取り下げたいような場合は、git revert でリリース時のコミットを打ち消すコミットを作るのがお作法です。 今回まさにそういう状況になったんですが、リリース時のコミットが複数回にまたがっており、それも 先のエントリ で書いたように他の対応と入り交じってコミットされてしまっています。 こういう場合にどう revert すればいいかという話です。 revert の基本的なところ 例えば 3a0e871f というコミットを打ち消したい場合は、 git revert 3a0e871fを実行すれば、 Revert "xxx 対応" This reverts commit 3a0e871ff60411ca89fa07c7f2b4d426fa04285d.のようなメッセージがみ
当然、ターミナルのプロンプトには表示させてますよね?zshならvcs_infoとか使えばいいですし。では、Vimはどうですか?各種git操作はVimからしないって?甘い、甘い。 git の branch を vim のステータスラインに表示 - #生存戦略 、それは - subtech 2008年3月のエントリですが、大変そうですね。でも今なら簡単です!fugitive を使えばいいんです!! ギットギトなVimmerにはすっかりお馴染みかもしれないfugitiveです。それ自体は VimmerなGit使いはfugitive.vimを今すぐ入れたほうがいい - SELECT * FROM life; や Vim-users.jp - Hack #219: Gitを使う2 – Fugitive.vim あたりが詳しいです。 :Gstatusからのstage/unstageが便利すぎますね!
ブランコ と同い年だったことが判明しました。みなさん、こんにちは nakamura です。あいつも昭和 55 年会か・・・。 Git をコマンドラインで使う利点は色々ありますが、git コマンド以外にも便利なツールがいくつかあるっていうのもひとつかなと思います。今日はそんな中でも個人的にこれないと困るわーっていうのを独断と偏見でご紹介したいと思います。 tig Index of /tig これはけっこう有名かも。いわゆるリポジトリブラウザです。カラフルで見やすいし、その場で任意のコミットの差分も見れちゃうのでリポジトリブラウザとしては git コマンドよりも格段に高機能です。 gitolite Hosting git repositories sitaramc/gitolite gitolite は Git リポジトリを管理するためのツールです。ドキュメントを少し読んでみれば分かりますが、
zshにおけるgitの補完関数の実装はいまいちでした。zsh + git使いはzshの補完関数_gitを速くしたい! その2のような対抗策を講じるか、gitのときだけbashを使うかしていました。僕は一時期後者でした。 さてgitのtarballにcontrib/completion/git-completion.bashというのがあるのはディープなgit使いならご存知かと思います。残念ながらファイル名の通りbashでしか使えませんでしたが、v1.7.4-rc0でzsh compatibleになりました add the following lines to your .zshrc: autoload bashcompinit bashcompinit source ~/.git-completion.sh と指示通りに.zshrcに追記するだけでzshでもbashなみの快適さでgitを使え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く