【バージョン管理ツール入門 第6回】
バージョン管理ツール入門：第1回｜第2回｜第3回｜第4回｜第5回｜第6回（今ここ）｜第7回｜第8回｜第9回｜[目次へ]
Gitの基本操作
Gitで最も重要な3つの操作
Gitでは次の3つの操作が基本になります。この3つを覚えれば、日常的な開発のほとんどをカバーできます。
add（追加）
変更したファイルを記録対象に追加する操作です。
コードを編集すると、Gitは「このファイルが変更された」と検知します。しかし、変更されたファイルは自動的にはcommitされません。まず「この変更を記録したい」と add で指定する必要があります。
git add .. は「カレントフォルダ内のすべての変更」を意味します。特定のファイルだけ追加したい場合は、ファイル名を指定します。
なぜ add が必要か：例えば、デバッグ用に一時的に書いた Console.WriteLine を、commit に含めたくない場合があります。add で選べることで、「記録する変更」と「記録しない変更」を分けられます。
commit（コミット）
変更履歴を保存します。
git commit -m "ログイン機能追加"-m の後ろに、その変更の内容を説明するコメントを書きます。後から履歴を見たときに「何をしたか」が分かるように、具体的に書きましょう。
よくある勘違いが「commit は保存（Save）と同じ」というものです。違います。Save はエディタの操作で、commit は「この状態を履歴として残す」操作です。Save しただけでは Git の履歴には残りません。add して commit して初めて履歴になります。
push（プッシュ）
GitHubなどのサーバに変更内容を送信します。
git pushcommit は自分のPCに履歴を保存するだけです。push すると、GitHub などのリモートリポジトリにその履歴が送られます。これにより、
- バックアップになる
- チームメンバーと共有できる
- 別のPCからもアクセスできる
ようになります。
学習時や業務では「今日の作業が終わったら push する」習慣をつけると、PCが故障しても安心です。
pull（プル）— 補足
pullは、リモートリポジトリの変更を自分のPCに取り込む操作です。push の逆です。
git pullチーム開発では、他の人が push した変更を pull で取得してから、自分の作業を進めます。これにより「誰の変更が最新か」が常に1つに決まり、上書き事故を防げます。個人で複数PCを使う場合も、作業開始前に pull すると、最新の状態から始められます。
実際の開発の流れ
実際の開発では
コードを編集
↓
add（記録したい変更を選ぶ）
↓
commit（履歴として保存）
↓
push（GitHub に送信）という流れで作業します。このサイクルを繰り返すことで、変更履歴が蓄積されていきます。
よくある失敗と対処
add し忘れて commit した：変更が commit に含まれていません。もう一度 add して commit し直します。
commit コメントを空で送った：後から何をしたか分からなくなります。できるだけ毎回、内容が分かるコメントを書きましょう。
push し忘れた：PC内には履歴がありますが、GitHub には残っていません。作業の区切りで push する習慣をつけると安心です。
1日の作業の終わりに
学習や業務では、その日の作業が終わったら「commit → push」まで行うことをおすすめします。これにより、自宅やリモートからもGitHub上でコードを確認できます。また、PCの故障や不具合があっても、GitHubに push しておけば復元が可能です。リモートワークが増えた今、push の習慣は特に重要になっています。
「編集 → add → commit → push」の流れを、毎日の習慣にしてみてください。
次回は、Gitと一緒に登場する「GitHub」について説明します。