gitで差分を1行単位でcommitするメリットと具体的な方法

こんにちは、フロントエンドエンジニアの「てりー」です。
僕の詳しいプロフィールはこちら

はじめに

チーム開発では、実際に本番環境に反映させたいコードのみを反映させることが重要になります。

commitメッセージに反する変更を加えずに開発を進めていく必要があります。
これができないとコードレビューの際に、「これ消しておいて!!」の様なあまり生産的じゃない指摘に時間を使ってしまいます。(僕はよくこれで怒られました!笑)


この記事では自分が意図していない変更を含まない為に、commitを細かく分割する方法をまとめました。
参考になれば幸いです。(作業環境はvscodeを想定しています)

もし普段は独学をしていてチーム開発経験がない方はこちらをご覧下さい!

関連記事

・未経験向けのチーム開発を経験して、脱未経験になってから転職orフリーランス独立を目指そう・未経験でもお金をかけずにチーム開発が経験出来るサービス紹介こんにちは、フロントエンドエンジニアのてりーです。僕の詳しいプロフィールはこち[…]

なぜcommitを細かく分割する必要があるのか?

commitは作業ログではなく、実現した事の単位で分割することが望ましいです
参考コミットは作業ログではない!

その理由について簡単にまとめると以下になります。

・レビューで指摘事項が複数になった時に、別々にcommitした方がレビュアーが確認しやすいから
実現したいことと関係ないコード修正はバグを生みやすいから
詳しく見ていきましょう!

レビューで指摘事項が複数になった時に、別々にcommitした方がレビュアーが確認しやすいから

Aの機能を作る際にそれと関係ないB、Cの機能のコード修正が入っていると、レビュアーはレビューしにくいです。

Githubでやり取りが往復してくると、いくつか指摘事項が重なる事があります。

レビュアー
AはuseRefの処理追加して
Bはいらないと思う

その時は一度のコミットで全部を修正するのではなく、Aの対応とBの対応のコミットを分割して「Aのcommitハッシュ + Aやりました」、「Bのcommitハッシュ + B消しました!」と伝えるとスムーズです!



実現したいことと関係ないコード修正はバグを生みやすいから

コミットする際はコミットメッセージの内容と異なる修正はしない事が望ましいです。
「Aの機能を直しましたー!」と書いてあるプルリクエストにBの修正が1行入っていても、気が付かない事は往々にしてあり得ます。


新人くん:「Aの機能を実装したぞ!!!、ついでにLintのエラーで気になってたBのコンポーネントも1行だけ直しちゃおう…」

新人くん:「コミットはまとめて1つでいいや。コミットメッセージは【Aの実装】と」

先輩:「レビューするか。おっ、Aの機能はちゃんとできてるな!LGTM」

1週間後:Aの機能をリリース!

先輩:「あれ、リリース後からなんかバグってるぞ?」

先輩:「Aの機能はレビューしたし、問題なかったぞ⁈」

先輩:「バグの原因はBのコンポーネントだったのか。Aしかいじっていないと思ったから、調査と対応に時間かかった…」


こんなことにならないように、コミットは実現したことの単位で細かく分けましょう!!

1行単位でcommitする方法

git add -p

git add -pを使うと全ての差分をステージングするかどうかの取捨選択ができます。
例えばこのような変更があったとします。


これにgit add -pを行うと

と変更差分ごとにY/Nでステージングするかどうかを選択できます。
多くの差分がある際に有効です。

 

vscodeから行う

vscode上で差分をステージングすることも可能です。

Image from Gyazo

目視で意図した通りに1行単位でステージングできます。

 

まとめ

commitやPRの粒度はプロジェクトによって変わってくる思いますが、基本的には以下に即して運用しましょう。

・コミットは実現した事の単位で細かく分割しよう
・コミットメッセージは修正の内容に則して書こう