git fetchとpullは何が違う？取り込む前に差を読む練習をしよう

リモートに更新があると聞いて、すぐgit pullしていないかな。まず変更を読みたいなら、git fetchで情報を取得する段階と、自分のブランチへ統合する段階を分けて考えられるよ。

この記事では、同じパソコンの中に作った練習用リポジトリだけを使う。Gitが導入済みで、コミット・ブランチの基本が分かる人向け。仕事用のリポジトリやインターネットへのpushは使わない。

fetchは、取得する操作

git fetch origin

通常の使い方では、リモートのオブジェクトや参照の情報を取得し、origin/mainなどのリモート追跡ブランチを更新する。現在チェックアウトしているmainの作業ファイルへ、そのまま変更を統合する操作ではないよ。

originは、リモートの接続先へ付けられる名前の一つ。必ず同じサーバーを意味する固定の名前ではない。まずgit remote -vなどで対象を確認しよう。

pullは、取得した後に統合する

公式資料では、pullはfetchを行い、その後、現在のブランチへ統合すると説明されている。統合方法はオプションや設定で異なるので、「pullならいつも同じ一種類の処理」とは考えないでね。

git pull --ff-only origin main

--ff-onlyは、履歴を前へ進めるfast-forwardができる場合だけ更新する指定。履歴が分岐している場合は、勝手にマージコミットを作ったりrebaseしたりせず停止する。ただし、更新を必ず成功させる指定ではないよ。

ローカルだけの練習を用意する

以下はPOSIX系シェルの例。空の一時フォルダに、共有先に見立てたbareリポジトリと、二つの作業用コピーを作る。bareは通常の作業ファイルを持たない保存先だよ。

practice_dir=$(mktemp -d)
git init --bare --initial-branch=main "$practice_dir/remote.git"
git clone "$practice_dir/remote.git" "$practice_dir/author"
cd "$practice_dir/author"
printf 'first
' > note.txt
git add note.txt
git -c user.name=Practice -c user.email=practice@example.invalid commit -m first
git push origin main
git clone "$practice_dir/remote.git" "$practice_dir/reader"
printf 'second
' > note.txt
git add note.txt
git -c user.name=Practice -c user.email=practice@example.invalid commit -m second
git push origin main

空の保存先をcloneしたときには、その旨の警告が出る。ここでは想定した状態。その後のコマンドが失敗したら、続けずに出力を確認しよう。

reader側で、ファイルがいつ変わるか見る

cd "$practice_dir/reader"
git fetch origin
cat note.txt
git diff HEAD..origin/main -- note.txt
git pull --ff-only origin main
cat note.txt

期待する結果は、fetch後のcatがfirst、差分にfirstからsecondへの変更、pull後のcatがsecond。編集部では、この順番を一時フォルダ内で実行し、作業ファイルが変わる時点を確認した。

停止したら、理由を確認する

実際の作業では、未コミットの変更や履歴の分岐などでpullが進まないことがある。git statusや履歴を確認し、作業の保持と統合方法を相談しよう。停止を消すためだけにresetなどの操作へ進まないでね。

この練習には、分岐を解消する操作は含めていない。現在のファイルとコミット予定の差を読むには、git diffの比較対象が別の確認になるよ。