前回の「Git基礎編」では、Gitの考え方と、リポジトリやブランチといった前提知識を学びました。本記事では、その知識を土台に、日常の開発でよく使うGitの基本操作を解説します。ファイルを変更してからチームに共有するまでの流れと、リモートの最新状態を取り込む流れを、操作によって状態がどう変わるのかを図で確認します。コマンドを丸暗記するのではなく、一連の流れとして理解していきましょう。
シリーズの全体像
このGit学習シリーズは、全部で4つの章に分かれています。
- 基礎編：Gitの考え方
- 基本操作編：毎日使う操作
- 実践・応用編：実務で使う操作
- コンフリクト編：競合への対応
前回は、第1章の「基礎編」として、Gitの考え方を学びました。本記事では、第2章の「基本操作編」として、ファイルを変更してから、その変更がチームに共有されるまでの一連の流れを順番に見ていきます。
この章で学ぶ2つの流れ
この章で学ぶ内容は、大きく2つの流れに分かれます。
1つ目は、変更を共有する流れです。ファイルを変更したあと、add で記録する変更を選び、commit で履歴として残します。その履歴を push でリモートに送り、必要に応じて merge で統合します。これが、Gitを使った開発の基本的な流れです。
2つ目は、最新の状態を取り込む流れです。fetch や pull を使い、リモートの最新状態をローカルに取り込みます。まずは、変更を共有する流れから順番に確認します。
1. ファイルを変更する
はじめに、main ブランチを起点に作業ブランチを作り、その作業ブランチ上でファイルを変更します。図の例では、Sample クラスを定義した Sample.java に、String name = "Git"; という1行を追加しています。
この時点では、変更した内容はまだGitの履歴として保存されていません。変更を履歴に残すため、続いて add と commit の2つの操作を行います。
2. addでコミットする変更を選ぶ
add は、次のコミットに含める変更を選ぶ操作です。この操作をステージングと呼びます。
図では、ファイルA、ファイルB、ファイルCの3つを変更した状態から、ファイルAとファイルBを add しています。これにより、2つのファイルがステージングされ、次のコミットに含める対象になります。一方、ファイルCはまだステージングされていません。
変更したファイルがすべて自動でコミットされるわけではありません。ファイル変更、ステージング、コミットという3つの段階を経て、変更が履歴になります。
3. commitで変更を履歴として確定する
commit は、ステージングした変更を履歴として確定する操作です。
コミットを行うと、新しい履歴が1つ追加されます。図では、今回の変更が「コミット履歴②」として、それまでの「コミット履歴①」の上に積み上がっています。
このようにコミットを重ねることで、変更の履歴が少しずつ蓄積されます。過去の変更を確認したり、必要に応じて以前の状態へ戻したりできることも、Gitの大きな特徴です。
4. pushする前の状態を確認する
作業ブランチに追加したコミット履歴②は、コミットしただけではローカル環境の中にしかありません。
Gitでは、コミットした変更がまず自分のローカルリポジトリに記録されます。このままではリモートに反映されないため、ほかのメンバーも変更を見ることができません。そこで使う操作が push です。
5. pushでリモートに反映する
push を行うと、ローカルの作業ブランチとコミット履歴②がリモートにも反映されます。これで、ほかのメンバーも変更を見られるようになります。
ただし、この時点では、変更はまだ main ブランチに反映されていません。次は、作業ブランチの変更を main ブランチへ取り込む merge を確認します。
6. mergeする前の状態を確認する
リモートへプッシュした作業ブランチには、今回の変更であるコミット履歴②が含まれています。しかし、この段階では変更が作業ブランチにあるだけで、チームの本流となる main ブランチにはまだ取り込まれていません。
作業ブランチの変更を main ブランチへ統合する操作が merge です。
7. mergeでmainブランチに統合する
merge は、ブランチを統合する操作です。マージを行うと、作業ブランチの変更が main ブランチへ取り込まれ、今回の変更が main にも反映されます。これで、リモートの main ブランチが最新の状態になります。
実際のチーム開発では、Pull Requestを作成し、内容をレビューしたうえで main へマージする流れがよく使われます。
8. pullが必要な状態を確認する
ここからは、リモートの最新状態を取り込む流れを見ていきます。まず確認するのは pull です。
先ほどのマージによって、リモートの main ブランチは最新の状態になりました。しかし、ローカルの main ブランチには、まだコミット履歴②が反映されていません。つまり、リモートとローカルで main ブランチの状態がずれています。
9. pullで最新の変更を取り込む
pull を実行すると、リモートの main ブランチの内容がローカルの main ブランチに反映され、両方の状態がそろいます。
ポイントは、pull がリモートの最新情報を取得するだけでなく、その内容をローカルのブランチへ反映するところまでまとめて行う操作だということです。
10. fetchが必要な状態を確認する
ローカル環境には、リモートブランチがどこまで進んでいるかという情報も保存されています。ただし、この情報は、リモートの変更に合わせて自動で最新になるわけではありません。
そのため、ほかのメンバーがリモートの main ブランチを更新すると、リモートはコミット履歴②まで進んでいる一方で、ローカルが持つ情報はコミット履歴①のままという状態が起こります。この情報を最新にするために使う操作が fetch です。
11. fetchでリモートの情報を取得する
fetch は、リモートの最新情報を取得する操作です。ただし、取得した変更を作業中のブランチへ自動では反映しません。
作業への反映はあとで行い、まずリモートの最新状況だけを確認したいときに使います。
12. pullとfetchの違い
pull と fetch は混同しやすいため、違いを整理しておきましょう。
fetch は、リモートの情報を取得するだけの操作です。作業中のブランチには反映しないため、まず状況を確認したいときに使います。
一方、pull は情報の取得に加え、ローカルへの反映までをまとめて行います。fetch と merge を続けて行うようなイメージです。「確認だけなら fetch、取り込むなら pull」と覚えておくと、両者を区別しやすくなります。
まとめ
本記事で学んだポイントは、次の2つです。
- 変更を共有する流れ
作業ブランチでファイルを変更し、addでコミットする変更を選びます。続いてcommitで履歴として確定し、pushでリモートへ反映したあと、mergeでmainブランチへ統合します。 - 最新を取り込む流れ
リモートの最新状態を確認するだけならfetch、最新の変更をローカルへ取り込むならpullを使います。
この2つの流れを押さえることで、Gitを使った基本的な開発の流れを理解できます。
