Gitで自分の作業中にmasterが更新された！安全に最新化してPushする手順まとめ

Git

Gitで新機能を開発している際、他のメンバーが master ブランチを更新することがよくあります。そのまま自分の作業を push しようとしてエラーに慌てないために、「安全に最新の master を取り込み、自分の作業と合流させる」正しい手順を徹底解説します。

前提知識

作業を始める前に、基本的な用語と概念を整理しておきましょう。

  • master（main）ブランチ: プロジェクトの本番用コードが管理されている場所。
  • 作業用ブランチ（例: test-branch）: 自分が今、新機能を作っている自分専用の場所。
  • リモート（origin）: GitHub上にあるリポジトリ（貯蔵庫）のこと。自分のPCの外にある「共有の場所」を指します。
  • マージ（Merge）: 2つの異なる歴史（ブランチ）を1つに合体させること。


実践手順：最新のmasterを取り込んでPushするまで

1. 自分の作業を「先に」コミットします。
まずは、今自分が書いたコードをローカル環境に保存します。

git add .
git commit -m "コミットメッセージ"
なぜ「先に」コミットするの？（重要）

Gitは「コミットされていない変更（作業途中の不安定な状態）」がある状態でのマージを推奨しません。先にコミットして自分の作業の歴史を確定させておくことで、この後の pull 作業で矛盾（コンフリクト）が起きても、Gitの機能を使って確実に元の状態に戻したり、差分を正確に比較したりできるようになります。未保存のまま進めると、作業内容が混ざってしまい、万が一の際の復元が極めて困難になります。

2. 現在のブランチを確認する
自分が今どのブランチにいるか確認します。* がついているのが現在の作業場所です。

git branch
# * test-branch
#   master

3. GitHub上の最新masterを取り込む（pull）
自分のブランチにいたまま、リモート（origin）にある最新の master を手元のブランチへ合流させます。

git pull origin master

4. 「マージコミット」を承認する
pull を実行した後、自動的にVS Codeなどのエディタが立ち上がり MERGE_MSG という画面が出ることがあります。これは「合体させた記録（メッセージ）」を履歴に残すための確認作業です。

具体的に何を合体させたのか？
GitHub上にある最新の masterブランチの内容と手元のPCにある test-branchブランチ（自分の作業）の内容の2つを合体させた、という事実を記録します。

操作：VS Codeなら画面上の「コミット メッセージを受け入れる」ボタンを押すか、ファイルを保存（Ctrl+S）してタブを閉じれば完了です。ターミナルの制御が自分に戻ります。

5. GitHubへ自分のブランチを送信（push）
手元のコードが「最新のmaster ＋ 自分の作業」が合体した状態（最新状態）になったら、GitHub側へ送信します。

git push origin test-branch
なぜ push が必要なの？

git pull origin master で行われた合体作業は、あくまであなたのPC（ローカル）の中だけで行われたものだからです。GitHub上の test-branch ブランチにはまだその結果が反映されていないため、最後に push して同期させる必要があります。

6. GitHub上で Pull Request（プルリクエスト）を作成・マージする
push が完了したら、仕上げにブラウザでGitHubを開き、公式に master へ合流させる依頼を出します。

  1. 「Compare & pull request」をクリック
    GitHubのリポジトリトップページに黄色いバーが表示されるので、ボタンをクリックします。
  2. 内容を確認して作成
    base: master ← compare:test-branch となっていることを確認。タイトルと説明を書いて「Create pull request」を押します。
  3. マージを実行する（Squash and merge のススメ）
    レビューが完了しマージする際、ボタン右側の矢印から 「Squash and merge」 を選ぶのがおすすめです。
  • メリット: test-branchでの細かい修正や「Merge branch…」といったシステム的なメッセージが1つに凝縮され、master の履歴があなたの代表的なコミットメッセージ（例：予算販管項目画面…）だけで綺麗に記録されます。


【コラム】git pull ではなく git fetch + git merge を使うべき？

中級者以上になると「pull ではなく fetch と merge を分けたほうが安全」と言われることがあります。

  • git fetch: リモート（origin）の最新情報をダウンロードするだけ。自分のコードは一切変わらない。
  • git merge: ダウンロードした情報を、自分のコードに合体させる。
なぜ分けるのが「安全」なのか？

fetch した後に git diff HEAD..origin/master というコマンドを打つと、実際にマージする前に「GitHub側で誰が何を変えたのか」を事前に偵察できるからです。「いきなり合体させてコードが壊れるのが怖い」という慎重な作業が必要な場面では、この偵察ステップを挟む手法が好まれます。


よくある疑問：GitHub上のコメントが混ざる理由

GitHubのファイル一覧に「Merge branch ‘master’ of…」というメッセージが表示されることがありますが、これは「正しく最新のmasterを取り込んで合体させた証拠」であり、正常な状態です。マージによってファイルが更新されたため、最新のコミットメッセージとして表示されているだけです。あなたの書いた「コミットメッセージ」という記録自体は、履歴の中にしっかりと残っているので安心してください。


まとめ：失敗しないための黄金フロー

  1. git commit：自分の作業を確定させ、保護する。
  2. git pull origin master：最新の土台（master）を自分の作業に合流させる。
  3. git push：合流済みの完成品をGitHubへ届ける。
  4. Pull Request：Squash and merge を活用して master を美しく保つ。

コメント

タイトルとURLをコピーしました