「ここまでコミットしておいて」
「コミットメッセージを書いて」
開発現場でよく聞く「コミット（Commit）」。日常語の「約束する」とは少し違う意味で使われます。
今回は、コミットをRPGの「セーブポイント」に例えて解説します。
結論：「コミット」＝「選んだ変更を、履歴として記録すること」
Gitにおけるコミットとは、「記録したい変更をひとまとまりにして、履歴へ残すこと」です。
ゲームでセーブした時点へ戻れるように、コミットを残しておけば、あとから変更内容を確認したり、問題のある変更を打ち消したりできます。
上書き保存とは何が違う？
Ctrl + Sで保存すると、作業中のファイルが更新されます。しかし、それだけでは「どこを、なぜ変えたのか」という履歴はGitに残りません。
コミットには、次の情報が記録されます。
- 記録した日時
- 記録した人の情報
- 対象となったファイルの状態
- 変更の目的を説明するメッセージ
ただし、コミットされるのは、あらかじめ選んだ変更です。未追跡のファイルや、選択していない変更まで自動で入るわけではありません。
良いコミットの作り方
1. 意味のある単位で分ける
「ログイン画面の表示を直す」と「料金計算を変更する」は、別の目的です。関係のない変更を1つにまとめると、あとで確認しにくくなります。
1つのコミットに、1つの目的。 これを意識すると履歴が読みやすくなります。
2. 理由が分かるメッセージを書く
「修正」だけでは、あとから見ても内容が分かりません。
- 分かりにくい例：
修正 - 分かりやすい例：
会員登録フォームの入力エラー表示を修正
何を変えたのかが伝わる言葉を選びましょう。
3. 動作を確認してから記録する
コミットは「必ず正しく動く保証」ではありません。保存前に、意図した変更だけが含まれているか、基本的な動作に問題がないかを確認します。
コミットはバックアップではない
コミットは、PC内のGitリポジトリに履歴を残します。ローカルでコミットしただけでは、PCやストレージの故障から守れません。
大切な履歴は、GitHubなどのリモートリポジトリへプッシュして、別の場所にも保存します。一般的なファイルのバックアップも併用すると、さらに安心です。
「戻す」にも種類がある
Gitでは、目的によって操作が変わります。
- revert： 過去の変更を打ち消す、新しいコミットを作る。
- restore： ファイルの内容を、指定した状態から取り出す。
- reset： ブランチや記録位置を動かす。使い方によっては変更を失うため注意が必要。
初心者のうちは「戻す＝全部同じ操作」と考えず、作業前に目的を確認するのが安全です。
まとめ
- コミット ＝ 「選んだ変更を履歴として記録すること」
- コツ ＝ 「1つの目的ごとに分け、内容が分かるメッセージを書く」
- 注意点 ＝ 「コミットだけではPC故障へのバックアップにならない」
コミットは、作業の区切りと理由を未来の自分や仲間へ伝える記録です。
次の記事では、別々に進めた変更を合流させる「マージ」について解説します。
ここまでお読みいただきありがとうございました！
QUICK CHECK
よくある質問
コミットすればバックアップになりますか？
同じPCの中にしか履歴がなければ、故障時に一緒に失う可能性があります。Gitの履歴をGitHubなど別の場所へ送ることや、別方式のバックアップも組み合わせます。
次に読むなら？
MERGEの記事へ進むと、開発や通信の流れを順番に理解できます。
参考資料
用語の定義や仕様を確認するため、公式文書・標準文書を参照しています。リンク先の内容は更新される場合があります。