Git push rejectedエラーの原因と対応方法を徹底解説

Gitでpushしようとしたときに発生する「push rejected」エラーの原因と解決方法を初心者向けに詳しく解説します。よくあるトラブルの背景やコマンド例をわかりやすく紹介。

「push rejected」エラーとは？

Gitで

git push

を実行した際に、以下のようなエラーメッセージが表示されることがあります：

fatal: Updates were rejected because the remote contains work that you do
not have locally. This is usually caused by another repository pushing
 to the same ref. You may want to first integrate the remote changes

このエラーは、ローカルとリモートの履歴が一致していないために、Gitが安全のためpushを拒否している状態です。

主な原因

1. リモートに自分が持っていない変更がある

他の人が先にリモートにpushしていた
GitHubなどでREADMEなどを編集してcommitしていた

2. ローカルにしか存在しない履歴を無理に上書きしようとしている

```
git init
```
→
```
remote add
```
→ いきなりpush という流れ

解決方法①：rebaseしてからpush

最も安全な方法は、リモートの変更を取り込んでからpushする方法です。

git pull origin main --rebase

この後、改めてpush：

git push origin main

なぜrebase？

rebaseは履歴を直列に並べるため、コンフリクトが起きにくく、履歴もきれいに保たれます。

解決方法②：マージしてからpush

マージで統合する方法もあります。

git pull origin main

その後：

git push origin main

ただし、マージコミットが不要な場合はrebase推奨です。

解決方法③：force push（※注意！）

どうしてもローカルの履歴を優先したい場合、強制的にpushすることもできます：

git push --force origin main

注意点：

リモートの変更履歴が完全に上書きされます
チームでの開発中には極力避けるべきです

エラー再発防止のためのポイント

push前に
```
git pull
```
を習慣にする
チームでのpushルール（誰がいつどのブランチにpushするか）を決めておく
定期的にリモートとの履歴を確認（
```
git log origin/main..HEAD
```
など）

まとめ

Gitの「push rejected」エラーは、リモートの状態とローカルが不一致な場合に発生します。慌てず、pull（rebaseまたはmerge）を行ってから再度pushするのが基本的な対処法です。force pushは慎重に使いましょう。