
Gitを使い始めると、かなり早い段階で「コミット」という言葉が出てくる。何となく保存のように見えるけど、普通の上書き保存とは少し役割が違う。
コミットは、ファイルの変更を区切りのよいところでGitの履歴に記録する操作だ。難しく考えず、まずは「あとから確認できるセーブポイントを作る」と覚えると分かりやすい。
Git自体がまだよく分からない場合は、先にこちらの記事を読むと全体像をつかみやすい。
今回はコミットだけに絞って、変更が記録されるまでの流れを短く整理する。
コミットは変更のセーブポイント

Git公式では、コミットはステージングした内容を新しいスナップショットとしてリポジトリに記録する操作と説明されている。
たとえばCSSを直して表示がうまく整ったとき、その状態をコミットしておけば「ここまでは正常だった」という区切りを残せる。後日さらに編集して問題が起きても、過去の記録と比べやすい。
ただし、ファイルを保存しただけではコミットにならない。通常の保存は現在のファイルを書き換える操作で、コミットはその変更をGitの履歴へ追加する操作だ。
変更してからコミットするまで

Gitでは、編集したファイルが自動的に全部コミットされるわけではない。基本は「変更する」「記録したい変更をステージングする」「コミットする」という流れになる。
現在の状態は次のコマンドで確認できる。
git status
次に、コミットへ含めたい変更をステージングする。すべての変更を対象にする簡単な例は次のとおり。
git add .
最後にコミットメッセージを付けて記録する。
git commit -m "記事の見出しデザインを調整"
最初のうちは、コミット前に git status で対象を確認する癖を付けておくと、関係ないファイルまで記録しにくい。
コミットメッセージは作業内容のメモ

コミット時のメッセージには、その変更で何をしたのかを書く。あとから履歴を見たときに、変更内容を思い出すための短いメモになる。
「修正」「作業」のような言葉だけでは内容が分かりにくい。「見出しの余白を調整」「投稿ランナーの検査を追加」のように、変更点が分かる言葉にすると探しやすい。
長い説明を書く必要はない。そのコミットに複数の無関係な変更が混ざっているなら、メッセージを長くするよりコミットを分けたほうが履歴を追いやすくなる。
コミットしただけではGitHubへ送られない

コミットはローカルのGitリポジトリに履歴を記録する操作だ。コミットしただけで、変更が自動的にGitHubへ公開されるわけではない。
GitHubなどのリモートリポジトリへ変更を送る操作は push と呼ばれる。つまり「コミットでPC内に記録し、必要ならpushでGitHubへ送る」という順番になる。
まずは、作業の区切りで変更内容を確認してコミットする。Gitを使い始めたばかりなら、この流れを覚えるだけでも履歴管理がかなり分かりやすくなる。







コメント