困りごと
試行錯誤を重ね、途中にデバッグコードが入ったりしているコミットが大量に含まれた状態で、そのままプルリクに出されるとレビュアーの労力が大きくなってしまう
注意事項
この記事は、
「統合ブランチのコミットはプロジェクトの履歴であり、個人の記録ではない」という思想に重きを置いて動いているプロジェクトに限った話になります。
取り扱わないこと
- コミットの粒度や単位をどのくらいの大きさにするべきか
１つのPRに対して、分岐点から最新コミットまでを、１つのコミットに纏めてしまう考え方を取り上げます。
今回の対象ケース
- 試行錯誤を重ね途中にデバッグコードが入ったりしているコミットが大量に含まれた状態で、そのままプルリクに出されるとレビュアーの労力が大きくなってしまう
今回の対象外のケース
- コミット粒度を細かく残しておくことに重きを置かれたプロジェクトなど。
▼Squash作業前▼ コミットの並び
$ git log --oneline
3jr0efj (HEAD -> topic) Last Commit
gdeq394 Comment 05
49rso9d Comment 04
7f4339j Comment 03
2f201gd Comment 02
s7d4jd7 Comment 01
9sae3ox (tag: release-v1.2.1) Merge pull request #53 from Foo/Bar
Interactiveなrebaseコマンドの挙動
$ git rebase -i {分岐点のコミットID} {纏めたい最新コミットID}
rebaseの開始点と終了点の指定
-
{第一引数}
- (必須パラメータ)
- コミットIDで指定 (ブランチ名指定も可能)
-
{第二引数}
- (省略可)
- [省略した場合：デフォルト値 = HEADのコミットID]
- コミットIDで指定 (ブランチ名指定も可能)
(手順1) 分岐点のコミットIDで、Interactive Rebaseを実行
# git rebase -i {分岐点のコミットID}
$ git rebase -i 9sae3ox
(手順2) デフォルトエディタ起動(vim)が自動起動
pick s7d4jd7 Comment 01
pick 2f201gd Comment 02
pick 7f4339j Comment 03
pick 49rso9d Comment 04
pick gdeq394 Comment 05
pick 3jr0efj Last Commit
# Commands:
# p, pick = use commit
# s, squash = use commit, but meld into previous commit
(手順3) pickをsquashに変える (１行目はpickにすること)
pick s7d4jd7 Comment 01
s 2f201gd Comment 02
s 7f4339j Comment 03
s 49rso9d Comment 04
s gdeq394 Comment 05
s 3jr0efj Last Commit
# Commands:
# p, pick = use commit
# s, squash = use commit, but meld into previous commit
- 上書き保存 (vimなら、
:wq)
(手順4) ２度目のvimの自動起動
- Squashで纏めあげたコミットメッセージを編集
- 「#」がついているところは、コメントアウト
- 「#」がついているところは、コメントアウト
今回は例として、コミットメッセージを以下のようにします。
Squashで１つに纏めたコミットです
- 上書き保存 (vimなら、
:wq)
(手順5) 完了
▼Squash作業後▼ コミットの並び
$ git log --oneline
83vdkwf (HEAD -> topic) Squashで１つに纏めたコミットです
9sae3ox (tag: release-v1.2.1) Merge pull request #53 from Foo/Bar
あとがき
コードをレビューしてもらう側の立場にいる際には
コードレビューをしてくださるレビュアーさんに
配慮したプルリクを送りたいですね。(自戒も込めて)
そして、レビュアーさんの負担を
減らすことができれば、
コードレビューの精度も上がり
結果的にチーム全体として
恩恵を受けられることに繋がるのかもしれません。