[GitHub入門]変更を確定！コミット実行とコミットメッセージの書き方

前回（リポジトリとREADMEから始める）では、リポジトリを作成し、開発環境を整えるところまでを行いました。

第3回となる今回は、いよいよ開発作業の基本サイクルである 「コミット（Commit）」 について解説します。
単にファイルを保存するだけでなく、意味のある単位で履歴を残す「コミット」の作法を学ぶことで、万が一のトラブル時にも数秒で過去の状態に復旧できるようになります。

GitHub入門シリーズ 全10回

本記事は「GitHub入門」全10回のNo.3です。

• No.1：Git/GitHubの基本概念とGitHub導入による投資対効果(ROI)
• No.2：リポジトリとREADMEから始める
• No.3：変更を確定！コミット実行とコミットメッセージの書き方
• No.4：VS CodeでGitを使いこなす マージ・コンフリクト・便利機能
• No.5：Issue（イシュー）でタスク管理
• No.6：Pull Request（PR）とコードレビュー
• No.7：ブランチ戦略の比較 Git Flow、GitHub Flow、GitLab Flow
• No.8：GitHub Actions CI/CDで自動化
• No.9：Code Scanning・Dependabot セキュリティの自動化
• No.10：なぜGitHubが高パフォーマンスチームを作るのか

今回のゴール

1. コミットとステージングの概念を理解する
2. VS Codeを使って変更をコミット・プッシュする
3. GitHub Copilotを使ってコミットメッセージを自動生成する
4. 履歴（History / Blame）を確認し、変更の意図を追跡する

コミット（Commit）とは？

コミットとは、ファイルの追加・変更・削除を 「リポジトリの歴史」として記録する操作のことです。
普段のエディタで行う「上書き保存」とは意味合いが異なります。

• 上書き保存: 最新の状態だけが残る。過去には戻れない
• コミット: ゲームの「セーブポイント」を作るようなもの。いつでもその時点の状態に戻れる

重要な概念「ステージング（Staging）」

Gitには、コミットする前に 「ステージングエリア」 という場所があります。
これは「買い物カゴ」に例えると分かりやすいです。

1. 作業ディレクトリ: 商品棚（変更したファイルすべて）
2. ステージング: 買い物カゴ（今回レジを通すファイルを選ぶ）
3. コミット: レジでの精算（確定してレシート＝履歴を発行する）

「AとBのファイルは修正したけど、今回はAだけコミットしたい」という時に、このステージング機能が役立ちます。

実践：VS Codeでコミットしてみよう

それでは、VS Codeを使って実際にコミットを行ってみましょう。

手順1：ファイルを変更する

まずは、前回作成した README.md を適当に編集して保存してください。
例として、以下のような行を追加してみましょう。

## 学習履歴

- リポジトリを作成してcloneを実施
- commitを実施

手順2：ソース管理パネルを開く

VS Codeの左側にある「ソース管理（枝分かれのようなアイコン）」をクリックします。
ここに、変更されたファイルの一覧が表示されます。

手順3：ステージング（買い物カゴに入れる）

変更されたファイル名（README.md）の横にある「+」アイコンをクリックします。
すると、ファイルが「変更（Changes）」欄から「ステージされている変更（Staged Changes）」欄に移動します。

これで、コミットする準備が整いました。

手順4：コミットメッセージを入力して確定

上部の入力欄に、どのような変更をしたのか説明を書きます。
入力したら、「コミット」ボタンをクリックします。

これで、変更がローカルリポジトリに記録されました！

良いコミットメッセージの書き方

コミットメッセージは、未来の自分やチームメンバーへの手紙です。
「修正」「update」といった曖昧なメッセージでは、後で履歴を見返した時に何が起きたのか分かりません。

基本フォーマット：Conventional Commits

開発現場でよく使われるConventional Commitsというルールを紹介します。
プレフィックス: 内容 の形式で書くことで、ひと目で変更の種類がわかります。

• feat: 新機能の追加 (feature)
  • 例: feat: ログイン画面に「パスワードを忘れた場合」リンクを追加
• fix: バグ修正
  • 例: fix: スマホ表示時にメニューが崩れる不具合を修正
• docs: ドキュメントのみの変更
  • 例: docs: READMEにセットアップ手順を追記
• refactor: 機能を変えずにコードを整理
  • 例: refactor: ユーザー認証のロジックを別ファイルに分離

もっと詳しく知りたい方は以下のサイトをご覧ください。

「What」ではなく「Why」を書く

コードを見れば「何をしたか（What）」は分かります。重要なのは 「なぜその変更が必要だったか（Why）」 です。

• ❌ 悪い例: style.cssの数値を変更
• ⭕ 良い例: fix: ボタンがクリックしづらいため、余白を8pxから16pxに拡大

【AI活用】Copilotにメッセージを書いてもらう

「適切な英語のメッセージが思いつかない」「変更箇所が多くて要約が面倒」
そんな時は、VS CodeのGitHub Copilot機能を活用しましょう。

コミットメッセージ入力欄の右側にある「キラキラ（✨）アイコン」をクリックしてみてください。
AIが変更内容（diff）を分析し、適切なコミットメッセージを自動生成してくれます。

生成されたメッセージを確認し、必要であれば微調整してコミットするだけです。これでドキュメント作成の手間が大幅に削減されます。
ただし、変更内容からAIが判断して生成しているため、先述した「Why」ではなく「What」が記載される可能性が高いので、参考として利用することをお勧めします。

GitHubへ送信：Push（プッシュ）

今のままでは、コミットは自分のPCの中だけに存在しています。
これをGitHub上のリポジトリにアップロードするためにPushを行います。

VS Codeのソース管理パネルにある「変更の同期（Sync Changes）」ボタンをクリックしてください。

これでGitHubのページを確認すると、編集した内容が反映されているはずです。

履歴の追跡とBlame機能

最後に、コミットを丁寧に積み重ねることのメリットを確認しましょう。

履歴を見る

VS Codeのエクスプローラーでファイルを選択し、「タイムライン」を開いたり、ソースコントロールの「Graph」を開くと、そのファイルに加えられた変更の歴史が一覧表示されます。
バグが混入した際、 「いつまでは正常だったか」 を特定する調査時間が大幅に短縮されます。

タイムライン
指定したファイルの履歴が確認できる

Graph
gitの履歴が確認できる

最終変更者と内容を確認（Git Blame）

「Blame（非難）」という怖い名前ですが、これは 「この行を最後に変更したのは誰で、それはいつ、どんな理由か」 を表示する機能です。

• 効果:
  • 「このコードの意味がわからない」という時、誰に質問すればいいか即座に判明します
  • 調査やコミュニケーションの迷いがなくなり、開発スピードが向上します

これらの情報を確認するためにはGitLensという拡張機能がおすすめです。

これをいれると、エディタ上のコード行に薄い文字で「誰が、いつ、どのコミットでこの行を書いたか」が表示されます。

また、先頭行の上に表示されている 2 authors (naoto hamada and one other)(回数や名前は履歴内容によって変わります)をクリックすると、各行の履歴が表示されます。

まとめ

今回は、Git操作の基本であるコミットについて解説しました。

1. コミット: 変更履歴のセーブポイントを作る
2. ステージング: コミットするファイルを厳選する（買い物カゴ）
3. メッセージ: feat: や fix: を使い、変更理由（Why）を残す
4. 履歴活用: 履歴を追跡して変更理由を知る

次回は、複数人で開発する際や、複数の機能を同時に開発する際に必須となる 「ブランチ（Branch）」と「マージ」、そして誰もが一度はハマる 「コンフリクト（競合）」の解決方法について、VS Codeを使ってわかりやすく解説します。