Gitの使い方メモ - sotarokのお勉強

Web+DB Press 50号に載ってるGitの特集がすごくわかりやすかった．
で，まあ，ただ読んでると頭に入ってこないから頭に入れたいところだけメモ．

git add

インデックスに追加する系．
インデックスは，次のコミットでコミットする変更を記録したもの．

git add <paths>	<paths> をインデックスに追加
git add .	現在のディレクトリ以下のすべての変更ファイル/新規ファイルをインデックスに追加
git add -u	インデックスから変更されてるファイルの変更をインデックスに追加
git add -A	-u + 新規ファイル
git add -p	たとえば index.html の変更箇所(hunk)が2つあったとしたら，その2つのうち片方だけをインデックスに追加みたいなことができる（対話形式で）

git commit

コミットする系．

git commit	インデックスの現在の状態をコミット
git commit <paths>	インデックスは無視して指定したファイルをコミット
git commit -a	ワークツリーにあるバージョン管理対象ファイルを全部コミット
git commit -v	パッチを再確認しつつコミット

git diff

diffとる系．

git diff	インデックスに記録した状態とワークツリーとの変更点
git diff --cached	最新のコミットとインデックスとの違い
git diff HEAD	最新のコミットとワークツリーとの違い

git log

ログ表示系．

git log	ログを表示
git log -<N>	N個分のコミットログ
git log -p	ログとパッチ
git log <paths>	<paths> が変更されたログ
git log --grep=<pattern>	ログメッセージに <pattern> を含むやつだけ

git revert / git checkout / git reset / git commit --amend / git rebase

過去に戻す系．

git revert <object>	過去のコミット<object>をなかったことにする．というか，svn的に言うと，逆マージ．<object>コミット前の状態を現在のワークツリーにマージ．<object>を探すのは git blame <path>
git checkout <paths>	<paths> をワークツリー状態からインデックスの状態に戻す
git checkout HEAD <paths>	<paths> をワークツリー状態から最新のコミットの状態に戻す．変更した箇所は捨てられる．
git reset --hard HEAD	前のコミット状態に戻す．ファイルの変更も捨てる．

コミットのやり直し系．

git reset <paths>	インデックスへの追加をなかったものにする．ファイルの変更は保ちつつ，addする前の状態に戻す感じ．
git reset HEAD	<paths> 使ったときの挙動をワークツリー全体に．
git reset HEAD^	1つ前のコミットをなかったことにする．ファイルの変更点は保たれるので，コミットを間違ったとか，そういうときに使う．
git commit --amend	1つ前のコミットをやり直しつつ現在のインデックスをコミット．git reset HEAD^ -> ファイル編集 -> git commit -a -m "hoge" と同じこと．ただし --amend と -m は同時に指定できない． -amend を指定したときは直前のコミットのメッセージが入力された状態でエディタが立ち上がる
git rebase -i HEAD~n	nコミット前までをやりなおし．エディタが立ち上がるので，pick/edit/squashを選ぶ（編集）．その後 git commit -amend -> git rebase --continue すると edit したコミットの書き換えができる．

rebase がすごい．すごすぎる．
前々回のコミットに含めたかったファイルなのにaddしてなかったーみたいなものを，rebaseで昔に戻ってaddしてgit commit --amend して git rebase --continueするといとも簡単に過去のコミットに変更を加えられる．

man git-rebase を見るとさらにハンパない機能を持ち合わせていることがわかる．たとえば，

       git-rebase --onto master next topic
       Another example of --onto option is to rebase part of a branch. If we have the following situation:

                                   H---I---J topicB
                                  /
                         E---F---G  topicA
                        /
           A---B---C---D  master

       then the command

       git-rebase --onto master topicA topicB
       would result in:

                        H’--I’--J’  topicB
                       /
                       | E---F---G  topicA
                       |/
           A---B---C---D  master

       This is useful when topicB does not depend on topicA.

だそうだ．

どんだけだ．
svnで歯がゆかった点もサポートしておりますね．すばらしいです．

今のところそんなかんじ．

ブランチ関係はまだぜんぜん使いこなせていない．ややこしいというか，自由すぎるｗ
まあとりあえずは基本的なところおさえたから良しですか？