Gitは非常にシンプルな分散型バージョン管理システム（VCS）ですが、その裏には複雑なワークフローやコマンドが存在します。その結果、時にはエラーに遭遇することも。エラーメッセージ「error: failed to push some refs to」には、解決方法がわからず、イライラさせられる方も多いはずです。
このエラーは、チームで1つのプロジェクトに取り組んでいて、リモートリポジトリにプッシュする際によく見られます。解決するには問題の原因を調査し、（再発を防ぐためにも）対策を講じなければなりません。
この記事では、Gitのこの「error: failed to push some refs to」エラーを解決する方法をご紹介します。まずは、このエラーの意味から見ていきましょう。
「error: failed to push some refs to」エラーとは
Gitの「error: failed to push some refs to」エラーは複雑ですが一般的に見られるもので、一般にリモートリポジトリに変更を反映しようとしたときに発生します。このエラーメッセージは、ブランチやタグなどの一部の参照に対してプッシュ操作が失敗したことを意味します。
具体的には、以下のような状況で発生します。
-
- リモートリポジトリに変更をプッシュしようとして、チームメンバーがすでに同じブランチに変更をプッシュしている場合。ローカルリポジトリとリモートリポジトリの競合（コンフリクト）が検出され、解決するまで変更を反映することができません。
- リモートリポジトリのブランチの更新や変更がローカルリポジトリに反映されていない場合。他の人が行った変更を上書きしたり失ったりすることのないよう、変更がプッシュできなくなります。
このエラーは、Gitが特定の参照（通常は特定のブランチ）をリモートリポジトリにプッシュしようとして問題が発生したことを伝えるものです。しかし、プッシュに失敗した原因を調査するように促されるだけで、問題の詳細は表示されません。
この記事の後半でご説明しますが、「error: failed to push some refs to」エラーを解決するには、ローカルリポジトリとリモートリポジトリの変更を同期することになります。リモートから最新の変更を取得し、競合する変更をマージしてから、プッシュを再試行します。
「error: failed to push some refs to」エラーの発生原因
「error: failed to push some refs to」エラーの原因は、基本的にローカルおよびリモートリポジトリ間で特定の参照が不一致であること。具体的には、以下のような原因が考えられます。
- 変更の競合─コードの競合は主な原因の一つで、誰かが同じブランチに先に変更を反映した場合、競合が検出され、その変更を上書きできなくなります。再度プッシュを行う前に、リモートリポジトリから最新の変更を取得し、ローカルの変更とマージするように促されます。
- ローカルリポジトリが古い─プッシュしようとしているブランチが、前回のプルや複製以降にリモートリポジトリで更新されている場合は、ローカルリポジトリにその更新が同期されていない可能性があります。この不整合が認識されると、変更が失われないようにプッシュを拒否します。
- パーミッションが不十分─リモートリポジトリに変更を反映する権限（パーミッション）がないことも考えられます。この場合は、再試行する前にリポジトリ管理者に確認する必要があります。
- リポジトリの設定─不正なアクセスURLや認証の問題、無効なリポジトリの設定など、リモートリポジトリまたはGitの設定そのものに誤りがあるかもしれません。
このエラーの解決方法は、ローカルリポジトリとリモートリポジトリを同期させること。次のセクションで、エラーの解決方法と今後発生しないための対策を見ていきます。
「error: failed to push some refs to」エラーを解決する方法（2ステップ）
これからご紹介する解決方法はやや長尺になりますが、手順は2ステップとシンプルです。まずは解決可能な単純な誤りがないかどうかを確認します。
1. 単純な誤りがないかを確認する
これはこのエラーに限ったことではありませんが、まずは基本的な設定や操作が正しいかどうかを確認しましょう。
最初のステップとして、2つのリポジトリを同期する前に、「error: failed to push some refs to」エラーを簡単に解決し得る方法を見ていきます。
正しいリポジトリを使用しているか
これは例えるなら、「コンピュータの電源が入っているか？」くらい初歩的な点ですが、正しいリポジトリにプッシュまたはプルできているかを確認して損することはありません。
まず、リモートリポジトリをチェックしましょう。任意のターミナルアプリを使用して、git remote -vコマンドで設定されているすべてのリモートリポジトリを表示します。リモートリポジトリのURLが目的のものと一致していることを確認してください。
次に、正しいブランチに変更を反映できているかどうか。git branchを使って、表示されたブランチ名を確認します。
ブランチを切り替える必要がある場合は、git checkout <branch-name>を使用してください。
次に、git statusを使ってローカルリポジトリの変更にエラーや未解決の競合がないかを確かめます。変更を再度反映する前に、表示された競合やエラーを解決しておきましょう。
準備ができたら、個別のファイルについてはgit add <file>、すべての変更を反映するにはgit add .を使用します。
なお、変更をコミットする際には、エラーの詳細を簡潔にメッセージで残すことをおすすめします。git commit -m "Your commit message"コマンドの「Your commit message」を実際のメッセージに置き換えます。
git pull origin <branch-name>を実行し、リモートリポジトリから最新の変更を取得してマージします。マージ中に発生した競合は解消してください。完了後、git push origin <branch-name>を使ってプッシュを再試行します。
なお、プッシュの承認と認証情報の入力が必要になる可能性もあります。プッシュが完了したらgit statusを実行し、コミットされていない変更や保留中の操作が残っていないかどうか確認してください。
作業ディレクトリとリポジトリのステータス
もう一つ簡単に確認できるのは、作業ディレクトリとリポジトリのステータス。
実行したコマンドが正しいことに自信があっても、タイプミスなどの誤りを確認するのは良いアイデアで、インターネット接続のテストにも役立ちます。ローカルおよびリモートリポジトリ間のパスに影響する可能性があるものは、すべて確認しておくのが賢明です。
これを確認するには、git statusを実行するだけ。すべての変更が反映されていることを確認したら、リポジトリのステータスに移りましょう。
他のステップと同様、git remote -vを使ってリモートリポジトリの設定を表示することができます。リモートリポジトリのURLが正しいことを確認したら、git branchを使用して正しいブランチにプッシュしていることも確かめましょう。
問題がないことを確認したらgit fetchを使用して、リモートリポジトリから最新の変更を取得します。次にgit merge origin/<branch-name>を実行し、取得した変更をローカルブランチにマージします。
再びマージの競合を確認したら、git push origin <branch-name>を使ってプッシュを再試行します。プッシュの承認がまた必要になるかもしれませんが、その場合はgit statusを実行して作業ブランチがクリーンな状態になったことを確認してください。
2. リモートリポジトリとローカルリポジトリを同期させる
単純な誤りなどがエラーの原因でないことを確認したら、具体的な解決策を講じましょう。大抵の場合は、単に2つのリポジトリを同期することで解決します。
ただし、権限に問題があると思われる場合は、リモートリポジトリの管理者に相談してください。
変更が競合していたり、リモートリポジトリがローカルリポジトリより先行していたりする場合は、git pull origin <branch-name>を実行し、リモートリポジトリから最新の変更を取得してマージします。
マージ中に発生した競合は解決します。解決後、変更をコミットしてgit push origin <branch-name>を実行し、リモートリポジトリに変更を反映してください。
リモートリポジトリのURLや設定に誤りがある場合は、git remote set-url origin <new-remote-url>を使って更新しましょう。
リモートリポジトリの正しいURLを設定後、プッシュを再試行してみてください。今度は問題なく実行できるはずです。
「error: failed to push some refs to」エラーの再発を防ぐには
このように、Gitの「error: failed to push some refs to」エラーは比較的すぐに解決できますが、エラーの再発を防ぐことも重要です。
まずは、パーミッションを確認しておきましょう。状況によっては、リポジトリのオーナーや管理者を通して行う必要があるかもしれません。また、同じリポジトリで作業している他の開発者と密にコミュニケーションをとることも重要です。コンフリクトや同期の問題を最小限にするため、ブランチ戦略やブランチの命名規則などのワークフローを最適化し、チーム内で必ず共有してください。
コミュニケーション方法以外にも、以下のような技術的なベストプラクティスが挙げられます。
- 共同作業や競合を減らすためにブランチを使用する。異なる機能やバグ修正のために別々のブランチを作成すれば、開発者同士が邪魔し合うことなく作業を行うことができます。
- 変更を反映する前には、必ずリモートリポジトリから最新の変更をプルするようにする。これによってローカルリポジトリを最新の状態に保ち、競合や古い参照が発生する可能性を最小限に抑えることができます。
- プル中に競合が発生した場合、プッシュする前にローカルリポジトリで解決する。Gitには、競合する変更を特定してマージするのに役立つツールがあります。
- リモートリポジトリのURLがローカルリポジトリで正しいことを確認する。必要に応じて、
git remote set-url origin <new-remote-url>で定期的にチェック。 - デプロイ前にステージング環境を使って変更をテストし、プレビューを行う。これによって早期に問題を特定し、スムーズなデプロイを行うことができます。
またリポジトリのステータスを監視し、更新の取り込み、競合の解消、変更のレビューなど定期的にメンテナンスも行いましょう。問題を完全に根絶することはできませんが、このような対策によって、再発を最小限に抑えることができます。
KinstaでGitを使用してサイトをデプロイする
Kinstaでは、Gitのシームレスな統合と高度なサポートを提供しており、WordPressサイトやアプリケーションの管理やデプロイを効率化することができます。
Gitリポジトリを直接接続することができるため、デプロイプロセスの自動化、コラボレーションの合理化、信頼性の高いVCSの確保を実現することができます。またSSHによって、接続も安全に保たれます。
例えばCI/CDパイプラインのセットアップなど、KinstaとGitを組み合わせることには数々のメリットがあります。GitLabユーザーであれば、完全自動化も設定可能で、人的ミスを軽減するだけでなく、サイトを常に最新の状態を保つことができます。
また、プッシュとデプロイも柔軟に行うことができます。Kinstaのお客様の多くはWP Pusherを使用していますが、BeanstalkとDeployBotも一定数の方が利用しています。
Kinstaのステージング環境を使用すれば、デプロイ前に変更をテストしたりプレビューしたりすることも。コマンドラインで自動化されたプロセスを組み込むことができるため、Git関連の作業に理想的です。
KinstaとGitを統合するには、「WordPressサイト」＞（サイト名）＞「情報」＞「SFTP/SSH」セクションにある認証情報を利用します。
この認証情報を使用して、コマンドラインからサイトにログインすることができます。KinstaでGitを使用する方法はこちらをご覧ください。
まとめ
Gitは、今日最も優れたVCSと言っても過言ではなく、開発プロジェクトのコード管理に必要なほぼすべての機能を提供しています。しかしエラーに遭遇すると、プロジェクト全体が一気に滞ってしまう可能性も。Gitの「error: failed to push some refs to」エラーが発生するとイライラしますが、その解決策は案外シンプルです。
まずは、正しいレポジトリと作業ディレクトリを使用しているかなど、単純な誤りがないかどうかを確認しましょう。その上で、2つのリポジトリ間ですべてのファイルとフォルダを適切に同期します。
Kinstaでは、業界トップクラスのアプリケーション＆データベースホスティングを提供しています。新たにワークフローを構築する必要はなく、エラーを最小限に抑え、リモートリポジトリでフルスタックのアプリを数分でデプロイすることができます。データセンターは世界25箇所、リソースの使用量に応じたシンプルな価格設定をご用意しています。
Git の「error: failed to push some refs to」エラーの解決方法について、ご質問がありましたら、以下のコメント欄でお聞かせください。
