2012年 10月 16日
git checkout another_branch
にすら時間がかかる……というのは大規模なプロジェクトだとありがちです。
例えば
master
にコミットがとんでもなく積み重なっているという状況を考えてみましょう。
普通なら
git checkout master
git pull
だけで自分が居ない間に行われた修正が取り込めますが、
checkout
前のブランチと master
が結構背離してて作業ツリーの更新に時間がかかるpull
ですぐに上書きされるという精神衛生上大変よろしくない事態が発生します。
どうにかしてブランチを checkout
せずに共有リポジトリの取り込むことができないものでしょうか。
git branch -d master
git fetch
git branch master origin/master
しかしこれだと手違いで自分のリポジトリの master
にしかない変更点があった時に気付けないままなのでよろしくありませんね。
push
するgit fetch
git push . origin/master:master
git push
は引数を色々と省略できるのですが、省略せずに使うと git push $remote $local_branch:$remote_branch
になります。意味としては「$remote
リポジトリの $remote_branch
ブランチを自分のリポジトリの $local_branch
で更新する」になります。
$remote
には push
先のリポジトリのアドレスを指定します。これは URL でも構いませんし、ローカルマシンにあるリポジトリなら普通のパス(/foo/bar/baz
等)でも構いません。ということは現在のリポジトリそのものは .
で表すことができます。
であれば fetch
してきた master
の内容を手元の master
に反映するのは git push . origin/master:master
でできる、という訳です。
しかし master
から origin/master
へ fast-forward できない場合は push
できません。そういう場合は素直に checkout
してから merge
する必要があります。ただまあこういう小手先のテクニックが必要に感じるケースは統合ブランチが相手なので fast-forward 出来ないというケースはまずないでしょう(というより出来なかったら何かがおかしい)。
git checkout master
git pull
先述のような小手先のテクニックを駆使するよりは素直に(あるいは富豪的に)処理の完了を待つというのも一つの手です。
次回は Mercurial 編です。