Git入門:バージョン管理のきほん
変更を記録する(add と commit)
この回でやること
git add でステージに乗せ、git commit で履歴に刻むまでの一連の操作を、実際のコマンドと出力を追いながら手を動かして覚えましょう。
- 読む 約 6 分
直した 2 か所が、まとめて 1 つの記録になる
作業中に、直したかった不具合の修正と、ついでに気づいた誤字の直しを同時にやってしまうことがあります。この 2 つは別々に記録したい。あとで片方だけ取り消したくなる日が来るからです。
そのために、Git は編集したものをそのまま記録しません。間に 1 つ置き場所を挟みます。
プレーンテキスト
ワークツリー --git add--> ステージ --git commit--> リポジトリ
(編集する) (選ぶ) (記録する)ワークツリーは、目の前のフォルダそのものです。ステージは、次の記録に含めるものを並べておく待合室です。リポジトリは、コミットが積み上がる保管場所で、実体は .git の中にあります。
add で選び、commit で刻む
前回の続きで、まだ記録していない README.md を残します。
ターミナル
$ git add README.md
$ git status
On branch main
No commits yet
Changes to be committed:
new file: README.mdgit add は成功しても何も表示しません。Git は成功時に黙るコマンドが多く、これで正常です。結果は git status で見ます。Untracked files にいた README.md が Changes to be committed、つまりステージに移りました。
刻みます。
ターミナル
$ git commit -m "初回コミット"
[main (root-commit) 8f3d2a1] 初回コミット
1 file changed, 1 insertion(+)main は今いるブランチ、8f3d2a1 がこの記録の名前、1 file changed が集計です。この数字が思っていた数と違ったら、その場で気づけます。 add し忘れがいちばん出やすいのはここです。
次に、ファイルを 2 つ触ってから、意味ごとに分けてみます。
ターミナル
$ echo "console.log('hello');" > app.js
$ echo "Git の練習用リポジトリです。" >> README.md
$ git add app.js
$ git commit -m "hello を出力するスクリプトを追加"
$ git add README.md
$ git commit -m "README にリポジトリの説明を追記"同じタイミングで編集した 2 つが、別々の記録になりました。ステージが無ければ、まとめて 1 つにするしかありません。
git add . と打てば、今いる場所より下を全部まとめて並ばせられます。速いのですが、パスワードを書いた設定ファイルや巨大な生成物まで巻き込む事故は、ほぼここから起きます。何が並ぶのかを git status で見てから打ってください。
add したあとに直すと、古いほうが記録される
git add は、その瞬間の中身をステージに写す操作です。写したあとにもう一度そのファイルを編集すると、ステージには古い中身、手元には新しい中身が入ります。git status では同じ名前が 2 か所に出ます。
プレーンテキスト
Changes to be committed:
modified: README.md
Changes not staged for commit:
modified: README.mdこの状態でコミットすると、記録されるのはステージにある古いほうです。「直したはずの修正が入っていない」の正体はこれです。編集したら git add をやり直す、と覚えておけば防げます。
git commit -am "メッセージ"と書くと add を省けますが、対象は追跡済みのファイルだけです。新しく作ったファイルは含まれません。慣れるまでは 2 つに分けて打つほうが確実です。
- ステージがあるから、同じ日に触った変更を意味ごとに分けて記録できる
git addは選ぶ操作、git commitは刻む操作。出力のN files changedを毎回読むgit addが写すのはその瞬間の中身。編集し直したら add もやり直す