git-pull、git-pull --rebaseをめぐる冒険＋コンフリクトした場合の作業

October 2008

September November

3rd Fri

git-pullで私なりの解釈で aha！が来たのでメモします。
これからは git-pull --rebaseにしよー
下記をそのままという感じなのですがｗ
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase

そういえばトッポさんが言ってた：git-pull --rebaseを使うといいよ

git-pullよりgit-pull --rebaseを使うといいよ(ただしという注意(下記太字)があるのでその辺は注意。ほとんどの人は関係ないと思うんだけど。。。)

Here's a tip for keeping up to date: In lieu of using git pull to download the latest changes, use git pull --rebase. Instead of cluttering the history with a merge commit, it reapplies your changes to the latest upstream. The only caveat is that you shouldn't use this method if you've already published the changes to another repository. Doing so would cause problems for anyone who has already downloaded the original commits.
http://www.tpope.net/rails-git-best-practices

でgit-pullとgit-pull --rebaseの違いをgit-rebaseの説明を読んで理解する

状況

o--o--O--o--o--o <-- origin
\
a--b--c <-- mywork

"mywork"は"origin" から単純に並行に行なわれています
プロジェクトの上流では他の興味深い変更が行なわれ、 "origin" は発展します

で、(上の状況から)git-pullした場合

o--o--O--o--o--o <-- origin
\ \
a--b--c--m <-- mywork

"pull" を使用して変更をマージさせることができます；結果として新しいマージコミットが生成されます

で、(上の状況から)git-pull --rebaseした場合

originが最新であればgit rebase originでいいと思うのだけど、(originが)最新でない場合はgit-pull --rebaseすればいいのだと解釈しました。

o--o--O--o--o--o <-- origin
\
a'--b'--c' <-- mywork

これは、mywork からあなたの各コミットを削除し、一時的に (".dotest" という名前のディレクトリ内に)パッチとして保存し、 mywork を origin の最新バージョンの位置に更新し、その後で保存した各パッチを新しい mywork ブランチに適用します。

コンフリクトがある場合は、下記にあるように修正してaddしてgit rebase --continueすればok。

各git-somethingでのコンフリクト時のリカバリ

git merge 時のリカバリ
o 手動マージ -> 動作確認 -> add -> commit

git rebase 時のリカバリ
o 手動マージ -> add -> git rebase --continue

git pull 時のリカバリ
o メンテナの場合 -> 一蹴
o ユーザの場合 -> 手動マージ -> add -> commit

git-am 時のリカバリ ( apply mail = メールで送られるパッチの適用 )
o メンテナの場合 -> 一蹴
o ユーザの場合 -> 手動マージ -> add -> git-am --resolved

http://d.hatena.ne.jp/conceal-rs/20080928/1222612534