Git rebaseについて

はじめに        

【エンジニア募集中】フルリモート可◎、売上/従業員数9年連続UP、平均残業8時間、有給取得率90%、年休124日以上 etc.  詳細はこちらから>

Gitには色んなコマンドがある。clonepullcommitmergeなど名前を見てすぐ使い方が分かるようなコマンドと違い、rebaseは一目で使い方や機能が分からないかもしれない。簡単に言うと、git rebaseは歴史の元を変更したり指定のコミットを編集したりするコマンドである。機能から見てもそんなに必要性を感じないけど、rebaseはとても魅力があるコマンドであると思う。うまく使えば、ソースコードの履歴が簡潔、分かりやすくようになる。

次に、rebaseの二つの使うシーンについて紹介する。

ブランチマージする前にリベースを使う

多人数共同開発では、ソースコードをマージすることが多いと思われる。

以下の開発状況が考えられる。マスタブランチMは開始時点とし、同時にブランチABA機能とB機能を開発している。

ブランチAとブランチBそれぞれマスタブランチMにコミットしたら、マスタブランチMのソースコードはコミットの時間順で表示すると以下のようになる。

リベースを使う場合では、ブランチAを先にコミットしたとして、ブランチBをコミットする前にrebaseを使う、最後にマスタブランチMは以下のようになる。


機能ABの実装が分かれていて、更新履歴が見やすいようになった。

リベースでコミットの履歴を修正する

一つ機能の開発で何回コミットする必要がある、以下のような状況が考えられる。

Aブランチのコミットが以下になる

A1:初期処理
A2:データ取得処理暫定
A3:命名規則により改修
A4:初期処理追加
A5:データ取得処理最終版
A6:結果出力

リベースを使ったら、A1からA6のコミットを以下のように修正できる

 A1’: 初期処理    (A1+A4+A3適用)
 A2’: データ取得   (A2+A5+A3適用)
 A3’: 結果出力    (A6)

コミットの修正にはpickrewordeditsquashfixupexecdropなどコマンドを使う必要がある。具体的使い方はここhttps://git-scm.com/docs/git-rebaseを参考してください。

注意点

上の紹介は全てローカルブランチ(プッシュする前の状態)に対する処理である。注意すべきことは既にプッシュされているコミットに対しリベースを絶対に使用しないこと。

まとめ

マスタブランチにコミットする前に、リベースでコミットを修正したり、プッシュ済みのソースコードに対してリベースしたりすると、ソースコード全体が簡潔、分かりやすくになる。

【エンジニア募集中】フルリモートも◎(リモート率85.7%)、平均残業8時間、年休124日以上、有給取得率90% etc. 詳細はこちらから>

Smallitのサービス