【備忘録】【git】ローカル変更がある状態で最新のリモート更新を安全に取り込む一般的な手順

ローカル環境に未コミット変更がある状態で、リモート側の最新更新を取り込む場面はよくあります。

このとき、状態を整理せずにそのまま pull を実行すると、競合や差分混在が発生しやすくなります。

そのため、先に変更を退避し、最新状態を取り込み、その後に必要な修正を最新コードに合わせて反映する流れが安全です。

基本方針

最も安全で説明しやすい手順は、次の順序です。

• 状態確認
• 変更を一時退避
• pull または rebase で最新化
• 取り込み後の状態確認
• 必要な変更を戻す、または最新コードに合わせて入れ直す
• 差分と動作を確認する
• 問題がなければコミットする

重要なのは、競合を完全に避ける事ではありません。競合しても安全に処理できる順序を作る事が本質です。

1. 作業ツリーの状態を確認する

最初に、現在の作業状態を確認します。ここで確認する対象は主に3点です。

• どのファイルに変更があるか
• どのブランチにいるか
• 未コミット変更が今回の作業分だけか

代表的な確認コマンドは次の通りです。

git status
git diff

この段階で不要な差分や一時ファイルが混ざっている場合は、先に整理した方が安全です。

2. 未コミット変更を一時退避する

状態確認後は、未コミット変更を一時退避します。一般的には stash を使います。

git stash push -m "before pull"

未追跡ファイルも含めて退避したい場合は、必要に応じて次のように実行します。

git stash push -u -m "before pull"

この操作の目的は、作業内容を失わないよう保険を作り、pull 前に作業ツリーをクリーンにする事です。

3. 最新のリモート更新を取り込む

作業ツリーがクリーンになったら、最新のリモート更新を取り込みます。一般的には pull –rebase が扱いやすい手順です。

git pull --rebase

この方法は merge commit を増やしにくく、履歴を比較的整理しやすいという利点があります。

ただし、チームで merge ベースの運用ルールがある場合は、そのルールを優先してください。

ここで競合が出た場合は、先に最新側で何が変わったかを確認する事が重要です。構造変更を理解しないまま機械的に進めると、後で不整合が起きやすくなります。

4. 取り込み後の状態を確認する

最新を取り込んだ後は、すぐに退避変更を戻さず、まず現在の差分と更新内容を確認します。

• どのファイルが更新されたか
• 自分が触る予定だった箇所に変更が入っていないか
• UI、設定ファイル、ルーティング、共通テンプレートなどに構造変更がないか

確認用のコマンド例は次の通りです。

git log --oneline --decorate -n 5
git diff HEAD~1

特に、影響範囲が広い共通部品や設定系ファイルは、変更内容を先に読んでおく必要があります。

5. 退避した変更を戻すか、必要なら入れ直す

次に、一時退避した変更を扱います。ここでは2つの判断があります。

• 対象ファイルの構造がほぼ変わっていないなら、stash を戻して調整する
• 対象ファイルの構造が変わっているなら、差分を参考にしつつ最新コードへ手で入れ直す

stash の一覧確認と適用例は次の通りです。

git stash list
git stash apply stash@{0}

apply は stash を残したまま適用できるため、慎重に進めたい場面で使いやすい方法です。

一方で、対象ファイルの構造変更が大きい場合は、機械的に戻すよりも最新コードに合わせて再実装した方が安全です。

実務では、共通コンポーネント、設定ファイル、ルーティング、テンプレート構造が変わったときほど、手で入れ直す方が事故が少なくなります。

6. 差分チェックと動作確認を行う

変更を戻した後は、必ず差分を確認します。ここで見るべきポイントは次の通りです。

• 余計なファイルが混ざっていないか
• 不要な差分が入っていないか
• 改行コードやフォーマット崩れがないか
• デバッグコードやコメントアウトが残っていないか

代表的な確認コマンドは次の通りです。

git status
git diff

加えて、必要最低限の静的チェックや動作確認も実施します。UI 変更なら画面確認、設定変更なら起動確認、API 変更なら主要処理の確認が必要です。

7. 問題がなければコミットする

最後に、今回の変更だけが含まれている事を確認してからコミットします。

• 今回の目的に関係ある差分だけか
• 不要な整形差分が混ざっていないか
• 暫定コードが残っていないか
• 必要なドキュメント更新が漏れていないか

この確認を行ってからコミットすれば、差分の意味が明確になり、レビューや後工程でも扱いやすくなります。

この手順のメリット

• pull 前の変更を失いにくい
• 競合時に原因を切り分けやすい
• 最新状態に合わせて実装し直せる
• 古い前提のまま変更を当てる事故を減らせる
• チーム手順やブログ記事として説明しやすい

注意点

• stash しただけで安心しない
• pull 後に最新差分を必ず読む
• UI 共通部品、設定ファイル、ルーティング、共通テンプレートは特に慎重に確認する
• 自動で戻せるからといって、常に stash pop が最善とは限らない
• 構造変更が大きい場合は、退避差分を参考に最新へ再実装する方が安全な事が多い

まとめ

未コミット変更がある状態で安全に最新を取り込むには、先に変更を退避し、最新化し、その後で最新コードを確認してから必要な修正を反映する流れが基本です。

順序としては、状態確認、退避、最新取り込み、差分確認、必要な変更の再適用、最終確認、コミットです。

この手順を徹底すると、競合そのものよりも、競合後の処理や差分整理を安全に進めやすくなります。