はじめに
Gitを使って開発を進める際、頻繁に登場するコマンドに push と pull があります。
「push すると何が起こるのか」「pull するとローカルにどんな変化が生じるのか」「両コマンドの使い分けはどうすればよいのか」といった疑問は、初心者だけでなく経験者でもつきまといます。
この記事では、まずGitのリモートとローカルの概念を整理し、続いてそれぞれのコマンドの実際の挙動と使い方を「例を交えながら」詳しく解説します。最後に、実際の開発フローに組み込む際の注意点やチームでの共通ルールの立て方まで掘り下げます。
1. Gitにおける「ローカル」と「リモート」って何？
| 用語 | 具体例 | 目的 |
|---|---|---|
| ローカルリポジトリ | 自分のマシン上の ~/project/ | コミット、ブランチ作成など、自分の作業スペース |
| リモートリポジトリ | GitHub/GitLab・自社サーバーの git@github.com:user/repo.git | 他人との共有、CI/CDの起点、バックアップ |
- ローカルリポジトリ には
git initで生成された working directory（ファイルが実際に置かれた場所） と index（ステージング領域） と ディレクトリ以下の.git/フォルダ が含まれます。 - リモートリポジトリ は実際にはサーバー上にある Git ディレクトリで、複数人が同時にプッシュやプルを行うことで同期が取れます。
2. git pull とは何か？
2.1 基本的な動作
git pull はローカルリポジトリにリモートリポジトリの更新を反映させるコマンドです。具体的には次の二ステップです：
- fetch（フェッチ）
git fetch origin <branch>でリモートのコミット情報を「ローカルのリモート追跡ブランチ」へ取得。 - merge（マージ）もしくは rebase
ローカルの現在のブランチにリモートの変更を統合。デフォルトはマージですが、--rebaseを指定すればリベースを行います。
$ git pull # デフォルト: fetch + merge
$ git pull --rebase # fetch + rebase
2.2 典型的なワークフロー
git pull→ ローカルの変更点をリモートの最新状態に同期。- もしローカルコミットが存在していれば、マージコンフリクト が発生する可能性がある。
- コンフリクトを解決後に
git commitを実行し、マージコミット（あるいは rebase のコミット）が作成される。
2.3 注意点
| 内容 | 詳細 |
|---|---|
| デフォルトのマージ | マージコミットができるので履歴が分岐します。頻繁に行うと履歴が煩雑になることがある。 |
| Rebase 推奨 | git pull --rebase をデフォルトに設定 (git config pull.rebase true) すると、直線的な履歴が保てます。 |
| 対象ブランチの指定 | git pull origin feature1 のようにブランチを明示すると意図せぬ統合を防げます。 |
3. git push とは何か？
3.1 基本的な動作
git push は ローカルリポジトリからリモートリポジトリへ コミットを送信します。基本的な構文は次のとおり：
$ git push <remote> <local_branch>:<remote_branch>
# 例:
$ git push origin main # ローカル `main` をリモート `main` にアップロード
3.2 リモート追跡ブランチとの関係
- upstream（上流）設定がある場合、
pushでは省略可。$ git push # upstream が設定されていれば push 先は自動で決定 git push -u origin feature2のように-u（–set-upstream）を付けると、今後git pushを単体で実行可能になります。
3.3 強制プッシュ（force push）
$ git push --force-with-lease
- リベース後にローカルコミットを再書き換えた ときに、リモートに上書きしたい場合に使います。
--force-with-leaseを使うと、自分の上書きが相手の最新コミットに合わない 場合に失敗。安全性が高い。
3.4 アクセス権限とトークン
- GitHub などでは PAT（Personal Access Token） が必要。
- SSH 鍵認証の場合は
~/.ssh/id_rsaがキー。 - 認証エラーは「無効な認証情報」か「権限不足」のどちらか。
4. pull と push の使い分け
| シナリオ | 何を行うか | 推奨されるコマンド |
|---|---|---|
| 最新状態を取得したい | 既存ブランチに他人のコミットを取り込みたい | git pull（または git pull --rebase） |
| 自分の変更を共有したい | 変更をリモートに反映させる | git push |
| 新しい機能作業開始 | チームで共有せずローカルに限定 | git checkout -b feature_x (push後は --set-upstream を設定) |
| リポジトリを複製・同期 | 新しいマシンに clone → pull で最新化 | git clone <url> 、必要に応じて git pull |
4.1 過密な Pull は不可
開発途中に頻繁に pull すると、マージコンフリクトが多発します。最小限に保つには：
- ブランチごとに作業分割：
mainは安定版、feature/*は作業中ブランチとして使う。 - Pull してからの作業：一度に大きなコミットを作らず、頻繁にコミットしてマージ可能性を減らす。
- ローカルで分岐：
git stashで一時的に変更を隠し、別ブランチでpull→stash apply。
4.2 Push でのバッチリチーム共有
- Pull Request (PR)：GitHub などでレビューを交えてマージ前に
pushする。 - protected branch：
mainやreleaseへの直接pushを制限し、レビュー済みPRのみをマージさせる。
5. 実際の開発フローで使う例
5.1 フロー例①：単機能開発
git checkout maingit pull --rebase– 最新を取得git checkout -b feature/awesome-feature- コミット →
git add ./git commit -m git push --set-upstream origin feature/awesome-feature- GitHub で PR 作成 → レビュー → マージ
git checkout main && git pull --rebasegit merge --ff-only feature/awesome-feature（GitHub 自動マージの場合は省略）git push origin main
5.2 フロー例②：定期的なリリース
mainで作業完了 →git push origin main- CI で自動テスト／ビルド → 成功時に
git tag v1.2.3→git push origin v1.2.3 releaseブランチ生成 (git checkout -b release/1.2.3) → 必要修正 →git pushreleaseブランチをmainに merge（Fast-Forward） →git push origin main
6. よくあるエラーと対処
| エラー | 原因 | 対策 |
|---|---|---|
error: failed to push some refs | 相手のリモートに自分のコミットに先行する変更がある | git pull --rebase で取込 → コンフリクト解決 → git push |
error: 'origin' does not appear to be a git repository | URL が間違っている、またはリモートが設定されていない | git remote add origin <url> で追加 |
username/password authentication failed | PAT が期限切れまたは無効 | 新しい PAT を生成し、git credential で更新 |
fatal: refusing to merge unrelated histories | 別々に初期化されたリポジトリをマージ | git pull --allow-unrelated-histories でマージを許可 |
fatal: Needed a single commit to be added to the index | マージコミットの途中で rebase を中断した | git rebase --continue で続行 |
7. マルチブランチ環境での注意点
- リモート追跡ブランチの管理
git fetch --pruneでデリートされたブランチをローカルから消す。git remote prune originも忘れずに。
- ブランチ名規則
feature/*、bugfix/*、hotfix/*などを明確に命名する。
- Protected ブランチ
- 誰が push / merge できるかを明文化（例：
mainは PR でのみ更新）。
- 誰が push / merge できるかを明文化（例：
- コミットメッセージ規約
- Conventional Commits（
feat:,fix:,docs:など）を採用すると CI の自動化がしやすい。
- Conventional Commits（
8. 最後に
pull：リモートの最新状態をローカルへ取り込む。マージまたはリベースで統合。push：ローカルの変更をリモートへ送信する。- 使い分けのコツは「まずは情報を取り込み、次に変更を共有」というタイムラインを守ること。
- チームでも共通の運用ルール（リベースかマージか、どこで
pushするか）を決めると、作業フローがスムーズになる。
Gitは非常に柔軟で多機能です。初めは push と pull の基本だけをしっかり身につけ、プロジェクトに合わせた細かな設定を段階的に増やしていくと、より効率的に高品質な開発が可能になります。ぜひ今回のポイントを試して、あなたのワークフローをさらに最適化してみてください。
コメント