Gitで「Updates were rejected because the remote contains work that you do not have locally」エラー

Git を利用して開発していると、git push を実行した際に 

Updates were rejected because the remote contains work that you do not have locally

というエラーメッセージに遭遇することがあります。これは Git を使ったチーム開発においてよく起こるエラーの一つで、リモートリポジトリとローカルリポジトリの状態に不整合が生じていることが原因です。

本記事では、このエラーが発生する背景と具体的な解決策を、実運用で使える形で整理していきます。Git 初学者だけでなく、日常的に利用しているエンジニアにとっても再確認の助けになるはずです。

目次

1. エラーの意味と発生する状況

このエラーは、リモートリポジトリに存在するコミットがローカルには存在せず、その状態で push をしようとしたときに出ます。Git は「リモートの履歴を上書きしてはいけない」という安全設計を持っているため、履歴の不一致があると push を拒否します。

例えば、次のような状況を考えます。

  • あなたが main ブランチをチェックアウトし、作業している
  • その間に別のメンバーがリモートの main に新しいコミットを push した
  • あなたが pull をせずに push しようとすると、リモートとの差分があるためエラーになる

表示されるエラーメッセージの例:

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.

このように、チーム開発や複数環境で同じブランチを扱っていると発生しやすいエラーです。

2. 解決策その1: git pull –rebase

最も推奨される方法は、リモートの変更をローカルに取り込み、履歴を整理してから push することです。ここで便利なのが git pull --rebase です。通常の git pull ではマージコミットが作成される場合がありますが、--rebase をつけると自分の変更がリモートの履歴の後ろに再適用されるため、履歴がきれいに保たれます。

実行手順は以下の通りです。

git pull --rebase origin main
git push origin main

この方法を使うと、リモートの更新を取り込んだ上で自分の変更を push でき、無用なマージコミットを避けられます。CI/CD 環境などで履歴の見やすさを重視する場合に特に有効です。

3. 解決策その2: マージを利用する

チームのルールによっては、git pull --rebase ではなく通常の git pull を利用することもあります。この場合、リモートのコミットとローカルのコミットを統合するためのマージコミットが作成されます。

git pull origin main
git push origin main

マージコミットが発生するため履歴は複雑になりがちですが、「いつどのタイミングで統合したか」が履歴として残るため、トレーサビリティを重視するチームではこの方式を採用することもあります。

4. 解決策その3: 強制 push (force push)

どうしてもローカルの履歴をリモートに上書きしたい場合には、git push --force を利用します。これは非常に強力で危険なコマンドであり、他の開発者のコミットを消してしまう可能性があるため、基本的には避けるべきです。ただし以下のようなケースでは選択肢となります。

  • 誤って余計なコミットを push してしまい、履歴を修正したい
  • 個人開発や誰も利用していないブランチを扱っている

コマンド例:

git push --force origin feature-branch

チーム開発ではこの操作を行う前に必ず関係者と合意を取る必要があります。事故を防ぐために、--force の代わりに --force-with-lease を使うのが望ましいです。これは「自分が知らないうちに他人のコミットが追加されていた場合は上書きしない」という安全機構が働きます。

5. 実運用でのトラブルシューティング

CI/CD 環境やチーム開発では、このエラーがビルドやデプロイのフローを止める原因となることがあります。以下のような対応が有効です。

  • CI で自動的に git pull --rebase を実行してからビルドを開始する
  • マージ戦略をチーム内で統一し、rebase 派か merge 派かを決めておく
  • 強制 push を行う場合は、Slack や Teams などで事前に周知してから実施する
  • 自動化されたジョブが強制 push をしないようにガードを設ける

また、頻繁にこのエラーが発生する場合は、複数人で同じブランチに直接 push していることが多いです。基本的にはプルリクエストやマージリクエストを経由し、main や develop ブランチへの直接 push を避ける運用にするのが望ましいです。

6. まとめ

本記事では、Git で「Updates were rejected because the remote contains work that you do not have locally」エラーが発生する原因と、その対処方法について整理しました。

  • 原因はローカルとリモートの履歴の不一致
  • 最も推奨される解決法は git pull --rebase でリモートを取り込み再適用すること
  • 場合によっては通常の git pull でマージコミットを作る方法もある
  • --force は危険だが、限定的な場面では有効な手段になる
  • CI/CD やチーム開発では再現性のある手順を統一し、トラブルを未然に防ぐことが重要

このエラーは Git を日常的に使っていると避けて通れないものですが、正しい理解と運用ルールの徹底によって効率的に回避できます。履歴管理をきれいに保ちながら、チーム全体の生産性を高めていきましょう。

参考

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