女性向けエンジニアスクール
3秒でわかる
リモートの変更を取得して、今いるブランチに取り込むまでを一度に行うコマンド。作業を始める前に手元を最新にするために使います。
もう少し詳しく
どういうものか
git pull は、リモートリポジトリの変更を取得する git fetch と、それを今のブランチに取り込む git merge を続けて実行するコマンドです。1つの操作に見えますが、中では取得と統合という性質の違う2段階が動いています。
git <a href="/glossary/fetch-api" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">fetch</a> リモートの内容を origin/main として手元に持ってくるだけ
作業中のファイルは1つも変わらない
git <a href="/glossary/merge" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">merge</a> origin/main の内容を、今いるブランチへ取り込む
ここで作業ツリーのファイルが書き換わる
git pull 上の2つを続けて実行するなぜ必要か
複数人で開発していると、自分が手元で作業している間に他の人の変更が本流へ入ります。古い状態のまま新機能を書き進めると、いざ統合する段になって大量の衝突が出ます。作業を始める前と、区切りごとに取り込んでおくと、衝突は小さいうちに片づきます。
具体例
# 現在のブランチにリモートの変更を取り込む
git pull origin main
# 何が来るのか先に確かめてから取り込む
git fetch origin
git log --oneline HEAD..origin/main # これから入る差分を確認
git merge origin/main
# 履歴を1本に保ちたいときはリベースで取り込む
git pull --<a href="/glossary/rebase" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">rebase</a> origin main
# 取り込み方の既定を設定しておく
git config --global pull.rebase false # merge で取り込む
git config --global pull.rebase true # rebase で取り込むつまずきやすいところ
手元に未コミットの変更があるとき、同じファイルがリモート側でも変わっていると pull は中断します。作業を失わないための保護なので、先にコミットするか git stash で退避してから実行します。
もうひとつ多いのが、pull のたびに増える空のマージコミットです。自分の変更をコミットしたあとに merge で取り込むと、履歴が枝分かれして「Merge branch main」という中身の無いコミットが積み上がります。1本の流れに見せたいなら --rebase を使いますが、すでに他人へ共有したコミットをリベースすると相手の履歴と食い違うので、共有前のローカルブランチに限ります。
衝突が起きたときに慌てて git checkout . などで消してしまう事故も起きます。衝突は、対象ファイルを開いて印の付いた部分を手で直し、git add して統合を完了させるのが正しい手順です。
似た用語との違い
| コマンド | 手元のファイル | 何をするか |
|---|---|---|
| git fetch | 変わらない | リモートの状態を取得するだけ |
| git pull | 変わる | fetch したうえで現在のブランチへ統合する |
| git pull --rebase | 変わる | 自分のコミットを取得分の後ろへ付け替える |
| git clone | 新規作成 | リポジトリ全体を最初に複製する |
覚え方
fetch は情報を見に行くだけ、pull は見に行って机の上まで反映する、と分けて覚えます。
