【ITニュース解説】Git Commit Best Practices: add -p, Messages & .gitignore

Gitを使ったバージョン管理において、効果的で質の高いコミットを作成するための重要な習慣について解説する。システムエンジニアを目指す初心者がGitを使いこなし、チーム開発で役立つスキルを身につけるための指針となるだろう。

まず、良いコミットの定義を理解することが重要だ。コミットとは、コードの変更履歴に記録される一つのかたまりである。良いコミットは、一つの論理的な変更のみを含み、その変更が何を意図しているのかを明確に説明できるべきだ。「請求書の合計の丸めを修正する」のように、単一の目的に焦点を当てたものが理想である。「丸めを修正し、ヘルパー名を変更し、依存関係を更新する」といった複数の変更を一つのコミットにまとめるのは避けるべきだ。もしコミットの件名に「そして（and）」を使わないと説明しにくいと感じたら、それは複数のコミットに分けるべき変更である可能性が高い。小さく、焦点を絞ったコミットは、コードレビューを迅速にし、問題が発生した場合に特定の変更だけを元に戻す作業（git revert）を安全にする。また、問題の原因を特定するgit bisectのようなツールが、より正確に犯人を見つけ出すのに役立つ。

次に、ファイルの変更の一部だけをコミットする方法を解説する。開発の途中で、一つのファイルの中で複数の異なる変更をしてしまうことはよくある。例えば、挨拶文の修正と請求書計算ロジックの変更を同じファイルで行った場合、通常のgit add ファイル名では両方の変更がステージングエリアに追加されてしまう。これを避けるためには、**git add -p（パッチモード）**を使うのが非常に有効だ。git add -p ファイル名と実行すると、Gitはファイル内の変更箇所（Hunk）を一つずつ表示し、そのHunkをステージングするかどうかを尋ねてくる。もし一つのHunkの中に複数の論理的な変更が混ざっている場合、sキーを押してHunkをさらに分割できる。これで、必要な変更だけを選んでステージングし、残りは後回しにできる。yでステージング、nでスキップが主な操作だ。ただし、git add -pはGitが既に追跡しているファイルに対してのみ機能する。新しく作成した未追跡ファイルを一部ステージングしたい場合は、まずgit add -N 新しいファイル名.txtを実行して「追加する意図」をGitに伝え、その後でgit add -pを使う必要がある。

コミットを実行する前には、ステージングエリアの内容を必ず確認する習慣をつけるべきだ。git add -pを使っても、誤って意図しない変更をステージングしてしまう可能性はある。コミットされる内容を確認するには**git diff --staged**を使う。これは、ステージングエリアの内容と直前のコミットとの差分を表示する。また、git diffは作業ツリー（現在編集中のファイル）とステージングエリアとの差分を表示し、まだステージングされていない変更を確認できる。これらのコマンドを習慣化することで、意図しないコミットを防ぎ、コミットの品質を向上させることができる。

読みやすいコミットメッセージの書き方も重要だ。Gitの公式ドキュメントでは、コミットメッセージの書式について明確な慣習が推奨されている。まず、50文字以内の短い一行で変更内容を要約し、その後に空行を一つ挟み、さらに詳細な説明を記述する形式だ。この最初の短い一行は、git log --onelineなどのコマンドや多くのWebUIでコミットのタイトルとして表示されるため、非常に重要である。良いコミットメッセージには三つの習慣がある。一つ目は、件名に命令形を使うことだ。「Add retry to webhook client」（Webhookクライアントにリトライを追加する）のように、「もしこのコミットが適用されたら、これは…するだろう」と読めるように書く。二つ目は、本文を約72文字で改行することだ。これはターミナルでgit logを見たときに読みやすさを保つための慣習である。三つ目は、変更の「なぜ」を説明することだ。コードの差分を見れば「何が」変わったかはわかるため、コミットメッセージでは「なぜ」その変更が必要だったのか、どのような背景や意図があったのかを記述することが重要となる。

直前のコミットを修正したい場合、例えばコミットに含めるファイルを忘れてしまったり、コミットメッセージにタイプミスがあったりした場合に**git commit --amend**コマンドが役立つ。これは、現在のブランチの先端にある直前のコミットを新しいコミットで置き換える。例えば、ファイルを忘れた場合は、git add 忘れたファイル名.txtを実行した後、git commit --amend --no-editとすれば、ステージングされた変更が直前のコミットに追加され、メッセージは変更されずに新しいコミットが作成される。メッセージだけを修正したい場合は、git commit --amend -m "新しいメッセージ"とすれば良い。ここで重要なのは、--amendを実行すると、結果として新しいコミット（新しいハッシュ値を持つ）が作成されるという点だ。この操作は、まだ誰もプルしていない（共有されていない）コミットに対して行う分には問題ないが、一度共有されたコミットに対して行うと、他の開発者の履歴と食い違いが生じる可能性があるため注意が必要だ。

リポジトリに含めたくないファイルを管理する方法として**.gitignoreファイルがある。これは、Gitが追跡しないようにするファイルやディレクトリのパターンを記述するもので、ログファイル、ビルド成果物、依存関係のディレクトリ、環境設定ファイル（.env）など、リポジトリに含める必要のない一時ファイルや機密情報を除外するために使う。例えば、.env、*.log、build/、vendor/、node_modules/といったパターンが一般的だ。パターンにはいくつかのルールがある。末尾にスラッシュ（/）を付けるとディレクトリのみにマッチし、先頭に!を付けると、そのパターンを否定し、無視しないようにできる。.gitignoreで設定したパターンが意図通りに機能しない場合は、git check-ignore -v ファイル名**と実行すると、そのファイルがどのルールによって無視されているかを表示してくれる。

.gitignoreに関するよくある間違いは、既にGitによって追跡されているファイルを無視しようとすることだ。一度コミットされて追跡対象になったファイルは、.gitignoreに記述されても無視されなくなる。この場合、そのファイルの追跡を停止し、かつローカルにはファイルを残しておくために、**git rm --cached ファイル名**を実行し、その変更をコミットする必要がある。これにより、以降Gitはそのファイルを無視するようになる。ただし、この操作は将来のコミットに対してのみ有効であり、過去のコミット履歴にはそのファイルの内容が残り続ける。

.gitignoreルールは、リポジトリのルートディレクトリに置かれチーム全体で共有されるもの以外に、個人の環境でローカルのみに適用したいルールを.git/info/excludeに記述したり、全てのGitリポジトリに適用したい個人的なルールをグローバルファイル（core.excludesFileで指定）に記述することもできる。これにより、プロジェクト共有の.gitignoreがそのプロジェクト固有の無視ルールのみを記述するように保つことができる。

最後に、**git checkoutコマンドに代わる新しいコマンドであるgit switchとgit restore**について説明する。git checkoutはブランチの切り替えとファイルの復元という二つの異なる役割を担っていたため、混乱を招きやすかった。Git 2.23以降、この機能がgit switchとgit restoreに分割され、それぞれの役割が明確になった。 **git switchはブランチ関連の操作に特化している。例えば、git switch mainでmainブランチに移動したり、git switch -c feature/xで新しいブランチを作成して移動したりできる。 一方、git restore**はファイルの復元やステージング解除に特化している。git restore --staged ファイル名はステージングエリアからファイルを解除する。git restore ファイル名は作業ツリーのファイルを、ステージングされている状態（または直前のコミットの状態）に戻し、未ステージングの変更を破棄する。これは非常に強力なコマンドであり、意図しない変更を簡単に失う可能性があるため、使用には細心の注意が必要だ。不安な場合はgit restore -p ファイル名（パッチモード）を使って、変更箇所ごとに破棄するかどうかを慎重に判断すると良い。

これらのプラクティスを実践することで、Gitの操作がより整理され、効率的になる。特に、git diff --stagedをコミット前の習慣とし、git add -pで変更を分割し、コミットメッセージには「なぜ」変更したのかを記述すること、そして.gitignoreを適切に設定して不要なファイルをリポジトリから除外することが重要だ。また、git restoreで未コミットの変更を破棄する際には、元に戻せない操作であることを十分に認識して慎重に行う必要がある。これらのベストプラクティスを身につけることで、システムエンジニアとしてのGit活用能力が大きく向上するだろう。