git rebaseとgit mergeの違いを確認する
今までgitでのブランチ統合は 「git merge」しか使ったことがなく、「git rebase」に対して「コンフリクトしたら面倒」というイメージがあり、ほぼ使ったことがありませんでした。
rebaseの方が履歴がキレイになるというのは認識していましたが、mergeで特に困っていなかったというのもあります。
ただ最近はフィヨルドブートキャンプでgitを基礎から学んでいることもあり、今まであまり使っていないgit操作も気になったら自分のテスト用のリポジトリで挙動を確認するようにしています。 サッとテストできるようにしておくといざミスったときに、『このコマンド実行したらできそうだけど、間違えたらどうしよう』というのが解消されたりするのでおすすめです。
とにかく試してみればわかる
以下のようなケースで試してみました。
ケース
- mainブランチから開発ブランチ（今回は
rebase_testブランチ）を切る rebase_testブランチへの追加開発用にrebase_test2とrebase_test3ブランチを切る- それぞれ変更を加えた後、先に
rebase_test2の変更がpushして、rebase_testにプルリク、マージされた状態。
やりたいこと
rebase_test3はまだローカルにのみ存在していてpushしていないので、rebase_test2の変更を取り込みつつ「rebase」を使って履歴はなるべくキレイに保ちたい。
補足
- rebaseとmergeの違いを確認したいので、今回は
git checkout -b rebase_test3_backupでrebase_test3のコピーをとっておく。
rebase/merge前の状態
rebaseした場合
// rebase_testにrebase_test2のマージをpull済みの状態 $ git switch rebase_test3 $ git rebase rebase_test
コミット番号が変わるが、ログ履歴がキレイになっている。（rebase_testとrebase_test3が一本化されている）
mergeした場合
// rebase_testにrebase_test2のマージをpull済みの状態 // rebase_test3のコピーブランチrebase_test3_backupで確認する $ git switch rebase_test3_backup $ git merge rebase_test
マージのコミットメッセージを編集してコミット
コミット番号は変わっていないが、履歴が複雑。＋マージコミットができている。
まとめ
今回やってみてrebaseの動きやmergeとの違いが改めてわかったので、ローカル作業では分岐元のブランチにリベースして履歴をキレイにして、pushするようにしていきたいなと思いました。チーム開発などでは方針にもよると思いますが、push済みのブランチに関してはいつどこでブランチ統合されたのかなど履歴を追えるmergeの方が適しているのかなと個人的には思ったり。あとrebaseをすると処理が作り直される（コミット番号が変わる）ので、チーム開発で既に参照されてるものをrebaseしてしまうと壊れてしまうのであまりやらない方がいいというのもありますね。
あとはこまめにcommitとpushをするようにするのが大事ですね。変更が多いほどコンフリクトが発生する可能性は高くなるので。
