hiyoko-programingの日記

プログラミングを勉強したてのひよっ子。   エンジニア目指して勉強中。

レビューを受けたあとの修正について

レビューを受けたあとの適切な修正とは、一言で言えば、きれいなコミットログが残っている状態にするということ。

まずは、良くないコミットの例を示す。
例えば、以下のようなコミットログが残っていたとする。

良くないコミットの例

ターミナル
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
#ログを表示(git logコマンドにオプションをつけることでログを見やすくしている)
git log --graph --all 

| *     Tue Oct 3 18:00:29 2017 +0900   28e76bb eichann 不要なファイルを削除  (origin/apply_to_design) (5 months ago)
| *     Tue Oct 3 18:00:10 2017 +0900   7612e69 eichann エラーを解消
| *     Tue Oct 3 17:45:28 2017 +0900   4c1efff eichann 投稿機能を作成
| *     Tue Oct 3 17:41:29 2017 +0900   fc8d52e eichann bootstrapを導入する為の記述
| *     Tue Oct 3 17:40:35 2017 +0900   2021dd0 eichann jsでbootstrapが適用されるように追記
| *     Tue Oct 3 17:39:04 2017 +0900   57cf022 eichann 必要なルーティングを追記
| *     Tue Oct 3 17:38:37 2017 +0900   7a02ce0 eichann 必要なviewファイルを追加
| *     Tue Oct 3 17:34:03 2017 +0900   ecdbbca eichann 必要な画像を追加
| *     Tue Oct 3 17:33:23 2017 +0900   1426e47 eichann bootstrap用のgemの導入

4,5行目に注目。「エラーを解消」「不要なファイルを削除」というコミットは、投稿機能作成についてレビューをもらい発覚した修正をするためのものだったとする。

こうしたコミットは本来、コミットログに残さない方が適切である。なぜなら、後から見返した際に邪魔な情報になってしまうから。また、Pull Requestのレビュワーにとっても不親切である。不要なコミットがあるとレビューをしずらくなる。

きれいなコミットログにするには

このような良くないコミットを残さないことが、きれいなコミットログを作る第一歩。
とはいえ、修正は必ず発生する。修正に伴うコミットをしたい場合は、どうすれば良いか?

Gitには、そうしたニーズに応えるための方法が用意されている。その内、rebasefixupについて紹介する。

rebaseについて

 git rebase -iコマンド

まず、rebaseコマンドそのものについて。
rebaseコマンドは、git merge(マージ)コマンドと同じように、2つのブランチを1つに統合するコマンド。mergeよりもrebaseの方がきれいなコミットを残すことができる。

rebaseコマンドの方がきれいなコミットを残せるわけ

git mergeコマンドを使うと、あるブランチを元のブランチに統合する際マージコミットと呼ばれるコミットが生まれます。これは、「マージしました!」ということを伝えるコミット。
翻ってgit rebaseコマンドは、マージコミットを残さない。「いつマージしたか」という情報はアプリケーションを作っていく上で重要ではないため、無い方がより良いと言える。

git rebaseコマンドの使い方について

以下の記事は参考。

git rebaseと仲良くなろう~part1

https://qiita.com/kkam0907/items/f92dd5288622387409be

Git のさまざまなツール - 歴史の書き換え

https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88

 

続いて、git rebase -iとして、-iオプションがついた場合について。

-iオプションをつけると、現在のブランチにおけるこれまでのコミットを操作することができる。
具体的には、以下のような操作が可能である。

・コミットメッセージの変更
・複数のコミットを1つにまとめる
・コミットの内容を改変する

具体的な使い方については、以下のブログ記事などが参考になる。

git rebase -i はやっぱりイケてる件【git】【rebase 】【iオプション】

https://otiai10.hatenablog.com/entry/2012/11/10/013925

Git のさまざまなツール - 歴史の書き換え

https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88

開発途中でコミットの粒度が適切でないと感じた場合は、積極的にgit rebase -iコマンドを利用する。

rebaseの使いどころ

実際にrebaseをどう活用したらいいのか?
rebaseは、ローカルでの開発におけるコミットを綺麗に整える目的で利用する。git mergeコマンドの代わりに使うことは推奨しない。git rebase -iという形は良いが、git mergeの代わりにgit rebaseを利用するのはやめておく。

git commit --fixupについて

 git commit --fixup

以下のように利用。

ターミナル
1
git commit --fixup コミット番号

こちらは、レビューを受けたあと修正を行う際に役に立つコマンド。--fixupを指定したコミットは、git rebase -iコマンドと組み合わせることで最終的に別のコミットに統合される。統合先のコミットは、git commit --fixup コミット番号のように予め指定する。
例を出すと、

良くないコミットの例

ターミナル
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
#ログを表示
git log --graph --all 

| *     Tue Oct 3 18:00:29 2017 +0900   28e76bb eichann 不要なファイルを削除  (origin/apply_to_design) (5 months ago)
| *     Tue Oct 3 18:00:10 2017 +0900   7612e69 eichann エラーを解消  (5 months ago)
| *     Tue Oct 3 17:45:28 2017 +0900   4c1efff eichann 投稿機能を作成  (5 months ago)
| *     Tue Oct 3 17:41:29 2017 +0900   fc8d52e eichann bootstrapを導入する為の記述  (5 months ago)
| *     Tue Oct 3 17:40:35 2017 +0900   2021dd0 eichann jsでbootstrapが適用されるように追記  (5 months ago)
| *     Tue Oct 3 17:39:04 2017 +0900   57cf022 eichann 必要なルーティングを追記  (5 months ago)
| *     Tue Oct 3 17:38:37 2017 +0900   7a02ce0 eichann 必要なviewファイルを追加  (5 months ago)
| *     Tue Oct 3 17:34:03 2017 +0900   ecdbbca eichann 必要な画像を追加  (5 months ago)
| *     Tue Oct 3 17:33:23 2017 +0900   1426e47 eichann bootstrap用のgemの導入  (5 months ago)

「不要なファイルを削除」「エラーを解消」というメッセージがついたコミットは、「投稿機能を作成」というコミットに対するレビューを受けての変更内容のコミット。

ということは、理想の状態は、レビューの内容を反映した「投稿機能を作成」というコミットが履歴として残ることである。

git commit --fixupコマンドは、まさにこの理想を実現してくれるコマンドである。

git commit --fixupの使い方

先程の例から時間をさらに遡り、レビューをもらった直後であると過程すると、コミットの履歴は以下のようになるはず。

良くないコミットの例

ターミナル
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
#ログを表示
git log --graph --all 

| *     Tue Oct 3 17:45:28 2017 +0900   4c1efff eichann 投稿機能を作成  (5 months ago)
| *     Tue Oct 3 17:41:29 2017 +0900   fc8d52e eichann bootstrapを導入する為の記述  (5 months ago)
| *     Tue Oct 3 17:40:35 2017 +0900   2021dd0 eichann jsでbootstrapが適用されるように追記  (5 months ago)
| *     Tue Oct 3 17:39:04 2017 +0900   57cf022 eichann 必要なルーティングを追記  (5 months ago)
| *     Tue Oct 3 17:38:37 2017 +0900   7a02ce0 eichann 必要なviewファイルを追加  (5 months ago)
| *     Tue Oct 3 17:34:03 2017 +0900   ecdbbca eichann 必要な画像を追加  (5 months ago)
| *     Tue Oct 3 17:33:23 2017 +0900   1426e47 eichann bootstrap用のgemの導入  (5 months ago)

このあとレビューを受けて「不要なファイルを削除」「エラーを解消」の作業が完了したとする。
この時、コミットの際に--fixupオプションを利用する。

ターミナル
1
2
3
4
#変更をadd
git add .
#fixupオプションを利用してコミット
git commit --fixup 4c1efff

最終的に統合したいコミットは「投稿機能を作成」のコミットなので、そのコミット番号を指定していく。

ここでログを見ると、以下のような形になる。

ターミナル
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
#ログを表示
git log --graph --all 
| *     Tue Oct 3 18:40:00 2017 +0900   geojsei eichann fixup! 投稿機能を作成 
| *     Tue Oct 3 17:45:28 2017 +0900   4c1efff eichann 投稿機能を作成
| *     Tue Oct 3 17:41:29 2017 +0900   fc8d52e eichann bootstrapを導入する為の記述
| *     Tue Oct 3 17:40:35 2017 +0900   2021dd0 eichann jsでbootstrapが適用されるように追記
| *     Tue Oct 3 17:39:04 2017 +0900   57cf022 eichann 必要なルーティングを追記
| *     Tue Oct 3 17:38:37 2017 +0900   7a02ce0 eichann 必要なviewファイルを追加
| *     Tue Oct 3 17:34:03 2017 +0900   ecdbbca eichann 必要な画像を追加
| *     Tue Oct 3 17:33:23 2017 +0900   1426e47 eichann bootstrap用のgemの導入

新たなコミットのメッセージは、統合したいコミットのメッセージに「fixup!」をつけたものになっている。この状態で、git rebase -iコマンドを利用する。その際、--autosquashというオプションを指定する。

ターミナル
1
2
#最新から4個前までのコミットについてをrebaseの対象とする
git rebase -i --autosquash HEAD~2

そのままrebase -iで必要な作業をせずにエディタを閉じ終了すれば、レビューを受けての変更は全て「投稿機能を作成」のコミットに統合される。これにより、あたかもレビュー後の状態を最初から実現できていたかのようなコミットを残すことができる。

再度修正をしてレビューをもらう際にプルリクエストに反映させるコミットは、fixupを利用してコミットする。