こんにちは。

自称コミットオプティマイズドアドバイザーの古里です。
今日は、「良い」コミットと「悪い」コミットについて話していこうと思います。

PR（プルリクエスト）のレビューを幾度となく経験した上で、良いコミットと悪いコミットを言語化してみました。良いコミットを知る前に、まずは悪いコミットの例を見て、理解を深めましょう。

「悪い」コミットの例

悪いコミットの典型例です。

例: fix、update、変更した

例:1000行以上の変更を1コミットに詰め込む

大規模な修正で本当に1000行以上の変更が必要な際は例外です。

コンテキストという抽象的な単語を使いましたが、ここでのコンテキストは、「目的・背景・意図」の意味で利用しています。

例えば、1つのコミットに「新規機能」と「リファクタリング」が含まれていると、2つのコンテキストがあると解釈します。②の話とも被るのですが、同じような修正なのだが、意図が異なる場合、別のコミットに分けて欲しいと思うのです。

「良い」コミットとは

では、良いコミットとは何か？それを実現するためのポイントを紹介します。

これが一番伝えたいことです。

ここまで、「良い・悪い」コミットの話をしてきましたが、PRを出す側も意図的に分かりにくくしている訳ではないでしょう。

気づいたら、わかりにくいコミットが生まれている状況なのです。この理由については、コミット単体ではなく、タスクの切り分け方にも問題があると考えます。

つまり、PRを出す側ではなく、そもそもタスク依頼者側にも問題があるのではないか？という話です。

良いコミットは、単に「きれいな履歴を作る」だけではなく、チーム開発においてコミュニケーションコストを下げ、変更を管理しやすくするために重要です。

これらを意識することで、よりスムーズな開発が可能になると考えます！
試してみてね♡

Organizationやってます。