【git】git rebaseでなくgit mergeにするべきか
yu.miyoshi概要
git rebaseでなく、git mergeを使用するべきなのかについて記述する
TL;DR
コミットログの綺麗さを求めるのではなく、バグ発見時後の対応を考え、
git rebaseでなくgit mergeを使用する
rebaseかmergeのどちらを使うかについて検討
私は個人開発、チーム開発問わずGitを使用するなかで、最新の本線(ここではdevelopとする)のブランチへの変更があった際には、対象のトピックブランチ(ここではfeat/hogeとする)で以下のコマンドを実行していました
// 変更中内容を一時退避
$ git stash
$ git checkout develop
$ git pull origin develop
$ git checkout feat/hoge
$ git rebase develop
// 変更完了後push
$ git push -f feat/hoge
Gitを利用した開発で4年間ほど上記コマンドを使用してきました
pullの中でmmergeは使用されているものの、git merge xxxのようなコマンドはしばらく使った覚えがないくらいです。
mergeを使わない理由は、rebaseでは、コミット履歴が直線的になり分岐するブランチが無いというところです
rebaseで作られた過去ログの方が読みやすく、美しいと思っていたため使用していました
ですが、そもそも Git を使う理由は、コード内のバグ原因を突き止めたり、過去を振り返れるからためです
美しいという理由だけで直線的な歴史にしたいというrebaseは、Git を使用しているメリットを下げてしまいます
本線のブランチへの変更をrebaseを使用し取り込んだ際にコンフリクトが発生した場合、複数回コンフリクト解消をしなければならないですが、マージを使用することで、全コンフリクトが1回のコミットで解決できます
マージした結果として得られるマージコミットは、ブランチ間の統合点を明確に示しており、実際に何が起こったか、そしていつ起きたかを履歴でわらることができます
将来のためにmergeを用い、作成された正しいリポジトリの履歴は、rebaseで作成された履歴よりも有用になると思います
rebaseできるコミットログはきれいな履歴になり、開発者にとって魅力的ですが、機能的な観点からは推奨できないという判断になります
参考サイト