Gitを使い始めたとき、私は「コミット」「プッシュ」「プル」の3つの操作を何となく使っていました。
どれもファイルを保存する作業に見えて、違いがよくわからなかったのです。
しかし実際に手を動かして、それぞれがどこに何を保存しているのかを確認すると、明確に役割が異なることがわかりました。
1. 3つの操作の流れ
3つの操作を整理すると、次のようになります。
- コミットは自分のPC内での操作です。
作業ディレクトリからローカルリポジトリへの記録です。 - プッシュは自分からリモートへの送信です。
ローカルリポジトリからリモートリポジトリへ変更を送ります。 - プルはリモートから自分への受信です。
リモートリポジトリの変更をローカルリポジトリに取り込みます。
実際の開発では、次のような流れで3つの操作を使います。
- 作業開始前に
git pullで最新状態にする - ファイルを編集する
git commitでローカルに変更を記録する- 作業の区切りで
git pushしてリモートに送る - 次の作業前に再び
git pull
この流れを繰り返すことで、チーム全体が常に最新の状態で作業できます。
方向で考えると、プッシュとプルは正反対の操作だとわかります。
2. コミット：自分のPC内だけの記録
最初に試したのはコミットです。ファイルを編集した後、以下のコマンドを実行しました。
git add .
git commit -m "機能を追加"
Code language: JavaScript (javascript)このとき、変更内容は自分のPC内の「ローカルリポジトリ」に保存されます1。
リポジトリとは、変更履歴を記録する保管庫のようなものです。
2.1. 他の人には見えない状態
ここで重要なのは、コミットしただけでは他の人に変更内容が共有されないという点です。
GitHubやGitLabなどのサーバーには、まだ何も送られていません。
私はこれを「下書き保存」に例えています。
ブログの下書きを保存しても、公開ボタンを押さない限り誰にも見えないのと同じです。
2.2. なぜコミットが必要なのか
コミットは変更履歴の1つの節目を作ります2。
後から「あのときの状態に戻したい」と思ったとき、コミットごとに戻れるのです。
また、作業を細かくコミットすると、何をいつ変更したのかが記録として残ります。
これは自分自身のためでもあり、チームで開発するときには特に重要になります。
3. プッシュ：リモートへの送信
コミットした変更を他の人と共有するには、プッシュが必要です。
git push origin main
このコマンドを実行すると、ローカルリポジトリの変更内容が「リモートリポジトリ」に送信されます。
リモートリポジトリとは、インターネット上のサーバーにある共有の保管庫です。
よく使われるのがGithubというサービスです。
3.1. プッシュは「投稿」に似ている
プッシュを実行した瞬間、私のPCの中だけにあった変更が、チームメンバー全員がアクセスできる場所に置かれました。
これはまさに、ブログの下書きを公開する操作に似ています3。
公開ボタンを押して初めて、記事が読者に届くのです。
3.2. プッシュのタイミング
私は当初、コミットするたびにプッシュしていました。しかし経験を積むと、ある程度まとまった単位でプッシュする方が効率的だとわかりました。
たとえば、1つの機能を実装する過程で5回コミットしたとします。その5つのコミットをまとめてプッシュすれば、リモートへの通信回数を減らせます。
ただし、プッシュを忘れると他の人が最新の変更を見られないので、作業の区切りでは必ずプッシュするよう心がけています。
4. プル：他の人の変更を取り込む
チームで開発していると、他のメンバーが変更をプッシュします。
その変更を自分のPCに取り込むのがプルです。
git pull origin main
このコマンドを実行すると、リモートリポジトリの最新の変更が自分のローカルリポジトリに取り込まれます。
4.1. プルは「最新情報の取得」
プルを実行すると、他の人が追加した機能や修正したバグが、自分のPCの中にも反映されます4。
これはニュースアプリで最新記事を取得する操作に似ています。
更新ボタンを押さない限り、新しい記事は表示されません。
4.2. プルを忘れると起きること
私が失敗したのは、プルを忘れたまま作業を進めてしまったときです。
他のメンバーが同じファイルを編集してプッシュしていたのに、私は古いバージョンのファイルを編集していました。
そして自分の変更をプッシュしようとすると、エラーが出ました。
Gitは「リモートの方が新しいから、まずプルして最新状態にしてください」と教えてくれました5。このエラーは、変更の衝突を防ぐための仕組みです。
4.3. 作業開始前のプルが習慣に
この経験から、私は作業を始める前に必ずプルする習慣をつけました。
朝、PCを開いたら最初にプルする。これだけで、多くのトラブルを避けられます。
5. コミットとプッシュを分ける理由
初心者の頃、私は「コミットしたら自動でプッシュしてくれればいいのに」と思っていました。
なぜ2段階の操作が必要なのでしょうか。
実は、この分離にメリットがあるということです。
5.1. オフラインでも作業できる
コミットはネットワークがなくても実行できます。電車の中やカフェで、インターネットに接続していなくても、コミットして変更履歴を記録できるのです。
そして後でネットワークに接続したとき、まとめてプッシュすればよいのです。
5.2. 試行錯誤の記録を残せる
1つの機能を実装するとき、私は何度もコミットします。「とりあえず動く版」「バグ修正版」「リファクタリング版」というように、細かく記録します。
これらのコミットは、すぐにプッシュする必要はありません。ローカルで試行錯誤の記録を残しつつ、満足できる状態になってからプッシュすればよいのです。
場合によっては、プッシュ前にコミット履歴を整理することもできます。
これは「リベース」という操作ですが、それは別の話です6。
6. まとめ：3つの操作の本質
Gitのコミット、プッシュ、プルは、それぞれ異なる役割を持っています。
- コミットは自分のPC内に変更を記録する操作です。下書きを保存するように、いつでも戻れる地点を作ります。
- プッシュはローカルの変更をリモートに送信する操作です。投稿ボタンを押すように、変更を他の人と共有します。
- プルはリモートの変更を自分のPCに取り込む操作です。最新情報を取得するように、他の人の変更を受け取ります。
この3つを使い分けることで、チーム全体が効率的に、そして安全に開発を進められるのです。私自身、この違いを理解してから、Gitの操作に対する不安が大きく減りました。
- Gitでは、作業ディレクトリで編集したファイルを「git add」でステージングエリアに追加し、その後「git commit」でローカルリポジトリに記録します。この2段階のプロセスにより、コミットに含めるファイルを選択できる柔軟性があります。 – 公式ドキュメントで学ぶ Git/GitHubの違い（cloneからcommit・push・PullRequestまで）
- コミットは単なる保存ではなく、変更内容のスナップショットとして履歴に記録されます。各コミットには一意のハッシュ値（SHA-1）が割り当てられ、後からその時点の状態に戻ることができます。 – 【Git】commitとpushの違いとは？初心者にもわかりやすく解説
- git pushコマンドの基本構文は「git push <リモート名> <ブランチ名>」です。originは初期設定のリモートリポジトリ名で、mainやmasterはブランチ名を指します。プッシュすることで、リモートリポジトリに変更が反映され、他の開発者がgit pullでその変更を取り込めるようになります。 – 【初心者向け】git pull, git fetch, git pushで何が起きているか図解してみた
- git pullは内部的には「git fetch」（リモートの最新情報を取得）と「git merge」（ローカルブランチに統合）を組み合わせたコマンドです。fetchだけを実行すると、リモート追跡ブランチのみが更新され、作業ツリーは変更されません。より慎重に作業したい場合は、fetchとmergeを分けて実行する方法もあります。 – GitHubを使いこなすために必要な操作「push」について
- この仕組みはGitの重要な安全機能です。リモートに新しいコミットがある状態でプッシュしようとすると、「non-fast-forward」というエラーが発生します。これは、他の人の変更を上書きしてしまう危険を防ぐためです。まずpullして最新状態にし、必要であればコンフリクト（競合）を解決してから、再度プッシュする必要があります。 – 【GitHub / Eclipse】Gitコマンド「commit」「pull」「push」って何？？
- git rebaseは、コミット履歴を整理するための強力なコマンドです。複数のコミットを1つにまとめたり、コミットの順序を変更したりできます。ただし、リベースは過去のコミットを書き換える操作のため、既にリモートにプッシュしたコミットには使用すべきではありません。主にローカルでの作業中に使用し、プッシュ前に履歴を整理するのが一般的です。 – Git – リベース