Git 良い考え方 リベース

最近、以降に紹介する書籍を購入して、Gitを通じて分散バージョン管理に入門、バージョン管理に再入門しています。

ローカルでのバージョン管理の仕組みはとても軽快で、さくさく動くのがとても気持ちいい感じです。バージョン管理システムとしてもSubversionとは少し違った考え方もあり、理解できればより良い考え方といえると思います。今回は、その中で私がとても気に入ったgit rebaseの考え方を紹介したいと思います。

参考にした書籍

この書籍は、一人で管理する場合から始まり、チームでの開発の例、また自分がコミット権を持っていないオープンソースプロジェクトの参加の仕方など、かなり実践に近いかたちで書かれていて、とてもためになりました。
今回は上記の書籍によく使われている図の形を真似しています。書籍の上ではこのような図で上記に紹介したようなケースを表現してくれています。

rebaseを仕様する上で想定されるケース

さて、まずは想定されるケースについて説明します。

mergeをしてbranchをmasterに統合すると…

続いて、一般的に行われるmergeのケースを説明します。

20120312追記
この絵ではmergeではブランチのコミットが残らないと書いてありますが、正確には残ります。

$git log --oneline --graph

上記のコマンドを実行すると、ブランチとマスターのマージを含めたコミット状況がよく分かります。

rebaseでbranchをmasterに統合すると…

rebaseであれば、以下のような統合が行えます。

補足

いかかでしょうか？この考え方はよくできていると思います。もちろん、rebase時にもmerge時と同じようにコンフリクト(同一の変更箇所の衝突)が起こる可能性があり、mergeと同じように衝突箇所の検出を行うことができます。よく考えられた仕組みですね。

今後もGitをメインにしつつ、他のSCMも少しずつ学んでいけたいいなと思います。