プログラミング初心者がアーキテクトっぽく語る

見苦しい記事も多数あるとは思いますが訂正しつつブログと共に成長していければと思います

GitHubのMergeオプション

GitのWebUIからブランチをマージしようとするには3つの選択肢が出てくる。

  1. Create a merge commit
  2. Squash and merge
  3. Rebase and merge

前提

ブランチAをブランチBへマージする。


1. Create a merge commit

  • デフォルト
  • ブランチBの全コミットをブランチAへマージコミットを作成して追加する
  • ブランチBのコミットは全てブランチAに記録される
  • マージコミットのAuthorはブランチAになる
  • 全てのコミット履歴が記録されており情報量は十分
  • ブランチB上の試行錯誤による細いコミット履歴も引き継がれてしまいブランチAの履歴が見にくくなる


2. Squash and merge

  • ブランチBの全コミットをブランチAへマージコミットを作成して追加する
  • ブランチBのコミットがブランチAに記録されない点がCreate a merge and commitと異なる
  • マージコミットのAuthorはブランチAになる
  • ブランチAの履歴がすっきりするがAuthorまで不明だと経緯が不透明になるリスクがある
  • 以下のCLI操作と同様
$ git checkout master
$ git merge --squash <作業ブランチ名>


3. Rebase and merge

  • ブランチBの全コミットがブランチAにそれぞれ追加される
  • マージコミットは作成されない
  • YとZのAuthorは残る
  • ブランチAの履歴が一本になりかつAuthorの識別も容易
  • 以下のCLI操作と同様
$ git checkout <作業ブランチ>
$ git rebase master
$ git checkout master
$ git merge <作業ブランチ>


比較

履歴の多さ 履歴の綺麗さ 事故発生時の復旧難易度
Create a merge commit
Squash and merge
Rebase and merge

まとめ

Gitに慣れた人が揃っているならば3がベストだ。履歴が追いやすく、外注している場合などでも透明性を確保しやすい。

Gitに不慣れな人がいる場合や、そもそも履歴を重要視しない場合は1か2のいずれかを選ぶ。細かい作業履歴は不要で、すっきりした履歴が欲しいならば2。ぐちゃぐちゃでもいいから全作業履歴が残っていて欲しいなら1だ。