本記事を執筆した背景

以前、コミットログの修正でgit rebaseを使おうとしましたが、うまくいかず、かえってコミットログが追加され、更にカオスになった経験があります。
共同開発でrebaseを使う度に肝を冷やすため、体系的に学び、使いこなしたいなと思い立ちました。

目次

1. 本記事を執筆した背景
2. そもそもgit rebaseとは？
- 2.1 git rebaseの一般的な使用例: 作業ブランチに最新の情報を反映させる
- 2.2 git rebaseの応用: コミットログをまとめる
3. おわりに

そもそもgit rebaseとは?

そもそも、git rebaseとはどのようなコマンドなのかおさらいをします。
結論から言うと、git rebaseとは、コミットログを改変するためのコマンドです。

下記の使用例を見ながら理解していきましょう。

git rebaseの一般的な使用例: 作業ブランチに最新の情報を反映させる

イメージ図(引用元: IT Information)

上記の事例:

1. 新規機能の開発を頼まれ、コミットAから切って、featureブランチを作成
2. ところが、別ブランチでコミットD,Eが進み、これらを利用しないと開発出来ないことが判明。
3. どうにかコミットB,Cの情報をもったまま、コミットD,Eも取り込みたい。どうしよう。。

こんなときに、git rebaseが非常に有効です。
上記の図のようにrebaseを使用することで、A地点で切られたfeatureブランチをEに変更してあげることで、B,Cの情報を持たせたまま、D,Eを取り込むことが出来ます。

なぜなら、コミットAからコミットEに祖先を変更するというコミットログの改変に他ならないためです。

くどいようですが、git rebaseはコミットログを改変しているんだ~ということを意識することで理解度が高まると思います!!

git rebaseの応用: コミットログをまとめる

コミットをした後に、タイポ、print文の追加, Linterの適用など、チマチマしたコミットがたくさん積み重なってしまうことがあると思います。
これらを1つずつ見るのはレビュワーの負担になるため、適切な粒度でコミットをまとめる必要があります。

コミットログが不適切な事例:

コミットAから3回、小さなコミットをしてしまったという状況を想定します。

(引用: www-creators)

[コミットが積み重なってしまった状況]
A. 最初のコミット(commit-A)： 機能実装
    - 必要な機能を実装したが、軽微なミスに気づかずそのままコミット
1. タイポ修正
    - コード内のタイポを発見し、修正
2. エラーハンドリング
    - エラーを握りつぶしていたことに気が付き、修正
3. Linter適用
    - 2で実装した部分のLinterが適用されていなかったため、修正

1~3はすべて認知しているミスコミットです。なので1~3の修正は、本来は下図のようにコミットAに組み込むべきです。

(引用: www-creators)

おわりに

今回は、rebaseを用いてブランチの祖先の改変と、コミットをまとめる方法について紹介しました。
とはいえ、具体的な操作に戸惑うと思うので、次回の記事では、git rebaseの使用方法をハンズオン形式で説明したいと思います。

筆者のぼやき
紹介した事例は私がつい最近経験したものです。
自分ではきちんと確認しているつもりなのに、なぜか修正点が後から次々と見つかることが多いんですよね。こういう現象に名前があったりするのかな、、(笑)