Gitのステージングとコミットをマスターする：最初の変更

Gitのステージングとコミットの基本をマスターすることは、Gitを自信を持って使いこなすための最初の本当のステップです。ステージングにより、次のスナップショットに含める内容を正確に選択でき、コミットにより、将来の読者が理解できるメッセージとともにそのスナップショットを記録します。

各コミットを小さなレビュー可能な作業単位として扱えば、Gitははるかに使いやすくなります。変更を検査し、無関係な編集を分割し、パニックにならずにミスから回復できます。

ステージングエリアの仕組み

Gitは編集したすべてのファイルを自動的にコミットしません。作業ツリー、ステージングエリア、コミット済み履歴の3つに作業を分離します。

作業ツリーはプロジェクトフォルダです。エディタで編集するファイルです。

ステージングエリアは、次のコミットのためのGitのチェックリストです。git addを実行しても、まだ履歴は保存されません。次のコミットのために変更を選択しているだけです。

リポジトリ履歴は、すでに記録されたコミットのシーケンスです。

まずはステータスを確認しましょう：

git status

Gitは追跡されていないファイル、変更されたファイル、ステージングされた変更、現在のブランチを表示します。このコマンドはいつでも安全に実行でき、習慣にすべきです。

新しいファイルまたは変更されたファイルをステージングするには：

git add README.md

現在のディレクトリ以下のすべての変更をステージングするには：

git add .

このコマンドは便利ですが、注意して使用してください。.gitignoreが不完全な場合、無関係なファイル、ローカル設定、生成された出力をステージングする可能性があります。

より安全なレビューのために、最初に差分を確認します：

git diff

次に、一緒に属するものだけをステージングします：

git add src/app.js
git add README.md

ステージング後、コミットされる内容を確認します：

git diff --staged

これにより、ステージングされた正確なスナップショットが表示されます。何か間違っている場合は、コミットする前に修正します。

最初のコミットを行う

適切な変更がステージングされたら、コミットを作成します：

git commit -m "プロジェクトREADMEを追加"

メッセージは、あなたが行ったアクションではなく、変更内容を説明する必要があります。「変更」や「ファイルを更新」よりも「プロジェクトREADMEを追加」の方が有用です。

良いコミットには通常、1つの明確な目的があります。たとえば、デプロイスクリプトを更新し、同時にドキュメントページのタイプミスを修正したとします。これらは別々の変更です。別々にステージングしてコミットします：

git add scripts/deploy.sh
git commit -m "デプロイヘルスチェックを追加"

git add docs/setup.md
git commit -m "セットアップガイドのタイプミスを修正"

これにより、レビューが容易になります。また、デプロイの変更が問題を引き起こしても、ドキュメントの修正は問題ない場合、ロールバックも容易になります。

-mなしでgit commitを実行すると、Gitはエディタを開きます。これは、より長いメッセージが必要な場合に便利です：

デプロイヘルスチェックを追加

デプロイ完了前にサービスエンドポイントを確認します。
これにより、リリースプロセスの早い段階で失敗した起動を検出できます。

最初の行は短く簡潔にします。本文では、なぜ変更が必要だったのか、トレードオフについて言及することができます。

最近のコミットを表示するには：

git log --oneline -5

これにより、最新の履歴のコンパクトなビューが得られます。

ファイルの一部をステージングする

1つのファイルに複数の無関係な編集が含まれることがあります。Gitはパッチモードでファイルの一部のみをステージングできます：

git add -p src/config.js

Gitは各変更ハンクを表示し、何をするか尋ねます。一般的な選択肢は次のとおりです：

• y：このハンクをステージングします。
• n：このハンクをステージングしません。
• s：可能であればハンクをより小さな部分に分割します。
• q：パッチモードを終了します。

パッチステージングは、コミット前にクリーンアップする場合に便利です。たとえば、新しいタイムアウト設定を追加し、コメントを再フォーマットしたファイルが1つあるとします。タイムアウトの変更を1つのコミットにステージングし、コメントのクリーンアップを別のコミットにステージングします。

誤ってステージングした場合は、作業を破棄せずにステージングを解除します：

git restore --staged src/config.js

ファイルは作業ツリーで変更されたままです。ステージングエリアから削除されただけです。

ファイルのステージングされていない変更を破棄したい場合は、注意してください：

git restore src/config.js

このコマンドは、そのファイルのローカル編集を破棄します。最初にgit diffを実行して、何を失うのかを把握してください。

その他の回復パターンについては、Gitのミスを元に戻す方法を参照してください。

日常業務のためのコミット衛生

小さく焦点を絞ったコミットは、レビュー、テスト、元に戻すのが容易です。また、バグの発生箇所を見つける必要がある場合に、git bisectなどのツールをより便利にします。

次の習慣を使用します：

• ステージング前にgit statusを実行します。
• git addの前にgit diffを確認します。
• コミット前にgit diff --stagedを確認します。
• 無関係な変更は別々のコミットに保ちます。
• 何が変更されたかを説明するメッセージを書きます。
• プロジェクトが期待しない限り、生成されたファイルをコミットしないでください。
• シークレット、秘密鍵、ローカルの.env値を決してコミットしないでください。

実用的なワークフローは次のようになります：

git status
git diff
git add src/server.js
git diff --staged
git commit -m "欠落しているヘルスチェック応答を処理"
git status

このシーケンスは派手ではありませんが、ほとんどの初心者のミスをキャッチします。何が変更され、何がステージングされ、何がコミットされ、何が残っているかがわかります。

チームがpre-commitフックや自動フォーマットを使用している場合、フォーマットやテストを修正するまでコミットが失敗する可能性があります。エラーメッセージを読み、提案されたコマンドを実行し、結果の変更をステージングして、再度コミットします。

いつ助けを求めるか

誤ってシークレットをステージングまたはコミットした場合、間違ったブランチにコミットした場合、修正、元に戻し、リセット、または新しいコミットを作成するかどうかわからない場合は、助けを求めてください。これらの選択肢は、特にプッシュ後は異なる影響があります。

また、他の人がプルした可能性のあるコミットを書き換える前に、助けを求める必要があります。単純なローカルクリーンアップが、共有履歴を変更するとチームの問題に変わる可能性があります。

ステージングとコミットはGitのコアループです。変更を確認し、意図的にステージングし、焦点を絞った部分でコミットし、1か月後でも意味のあるメッセージを書きましょう。