VS CodeでWebサイトを制作していると、GitHubへ変更をプッシュした際に、突然エラーが表示されることがあります。
今回、ランディングページを制作していたところ、GitHubへプッシュできなくなりました。原因は、ローカルとGitHubの両方で同じブランチに新しい変更が追加され、変更履歴が二手に分かれていたことでした。
この記事では、今回のトラブルの原因や実際に行った対処方法、VS Codeの「出力」に表示されるGitのログについて、Git初心者向けに解説します。
今回起きたこと
作業していたブランチから新しいブランチを切って他の人が作業していました。
それ（他の人が作業していたブランチ）を私が作業していたブランチにマージした後の話です。
GitHub上の同じブランチには、6件のコミットが追加されていました。
一方、パソコン内のローカルブランチ（私が作業していたブランチ）にも、GitHubにはまだ存在しない新しいコミットがありました。
イメージすると、次のような状態です。
共通のコミット
├─ GitHub側：6コミット
└─ ローカル側：自分が作成した新しいコミットGitHub側とローカル側が、それぞれ別の方向に進んでいます。この状態を「履歴が分岐している」といいます。
なぜプッシュが拒否されたのか
通常のプッシュは、GitHub上の履歴の続きをローカルから追加するときに成功します。
しかし今回は、GitHub側にローカルがまだ持っていない6件のコミットが存在していました。
そのままローカルの内容をプッシュすると、GitHub側の変更を無視したり、変更履歴を壊したりする可能性があります。
そのためGitは、安全のためにプッシュを拒否します。
このとき、次のような内容のエラーが表示されることがあります。
rejected
non-fast-forward
failed to push some refs
fetch first表示内容は環境によって異なりますが、簡単にいうと次の意味です。
GitHub側に、自分のパソコンへまだ取り込まれていない変更があります。先にその変更を取り込んでください。
これはGitやGitHubが壊れたわけではありません。ほかの場所で追加された変更を守るための安全機能です。
今回行った対処
最初に、作業中の状態をバックアップ用ブランチへ保存しました。
バックアップを作っておけば、取り込み作業で問題が起きても元の状態へ戻しやすくなります。
その後、次のコマンドを実行しました。
git pull --no-rebase origin ブランチ名このコマンドでは、GitHubにある変更を取得し、ローカルの変更とmerge方式で統合しています。
今回の統合では競合が発生しなかったため、次の変更を両方とも残すことができました。
- GitHub側に追加されていた変更
- ローカルで作業していた変更
統合後に改めてプッシュすることで、GitHubへ変更を反映できました。
git push origin ブランチ名git pull --no-rebaseとは？
コマンドを分解して見てみましょう。
git pull --no-rebase origin ブランチ名それぞれの意味は次のとおりです。
git pullは、内部的にはおおむね次の2つの処理を続けて行います。
GitHubの変更を取得する
↓
ローカルの変更と統合する今回はローカルとGitHubの両方に残したい変更があったため、merge方式で統合しました。
「競合」とは？
GitHub側とローカル側で同じファイルの同じ部分を変更していると、Gitだけではどちらを残せばよいか判断できない場合があります。
これを「競合」または「コンフリクト」といいます。
競合が発生した場合は、VS Code上で対象ファイルを開き、どの内容を残すのか人間が判断する必要があります。
今回のケースでは変更箇所が重なっていなかったため、Gitが自動的に統合できました。つまり、競合は発生していません。
VS Codeの「出力」に大量に表示された文字は何？
VS Codeの画面下部にある「出力」でGitを選択すると、次のような表示が大量に出てくることがあります。
2026-09-27 02:42:54.582 [info] > git config --get commit.template [11ms]2026-09-27 02:42:54.586 [info] > git for-each-ref --format=...一見するとエラーのように見えますが、[info]と書かれているものは、基本的にエラーではありません。
VS CodeがGitの状態を確認するために、裏側で実行したコマンドの記録です。
git config --get commit.template
git config --get commit.templateこれは、コミットメッセージを書く際のテンプレートが設定されているかを、VS Codeが確認するコマンドです。
テンプレートが設定されていなくても、通常は問題ありません。
git for-each-ref
git for-each-refこれは、ローカルブランチやリモートブランチの情報を取得するコマンドです。
VS Codeはこの情報を使って、次のような状態を画面に表示しています。
- 現在選択されているブランチ
- GitHub側と対応しているブランチ
- ローカルが何コミット進んでいるか
- GitHub側が何コミット進んでいるか
- プッシュやプルが必要か
コマンド内の次のような文字も、Gitがブランチ情報を整形するための指定です。
%(refname)
%(upstream:short)
%(objectname)
%(upstream:track)自分で覚えたり入力したりする必要はありません。
また、コピーした文章に含まれる は、半角スペースを表すHTML上の文字コードです。Gitの重大なエラーを意味するものではありません。
[info]なら無視してもよい？
多くの場合、[info]はVS CodeとGitの通常の動作記録なので、問題ありません。
注意したいのは、次のような表記です。
[error]
fatal:
rejected
conflict
CONFLICT
failedただし、failedという単語が別の説明文の中に含まれる場合もあります。判断するときは、その行だけではなく前後の数行も確認しましょう。
Gitのトラブルを相談するときは、「出力」の最後の20～30行程度と、画面に表示されたエラーメッセージを一緒に伝えると、原因を特定しやすくなります。
同じトラブルを防ぐための習慣
作業を始める前に、GitHub側の最新状態を取り込んでおくと、履歴の分岐を防ぎやすくなります。
まず、現在のブランチを確認します。
git branch --show-current目的のブランチへ移動していない場合は、次のように切り替えます。
git switch ブランチ名その後、GitHub側の変更を取り込みます。
git pull --no-rebase origin ブランチ名普段の作業は、次の順番を意識すると安全です。
- 作業するブランチを確認する
git pullでGitHubの最新状態を取り込む- ファイルを編集する
- 変更をコミットする
- GitHubへプッシュする
作業途中でpullするときの注意点
ファイルを編集している途中でgit pullすると、未保存の変更や未コミットの変更とぶつかる場合があります。
まず、現在の状態を確認します。
git status変更が残っている場合は、コミットしてから取り込むのが分かりやすい方法です。
git add .
git commit -m "作業途中の内容を保存"
git pull --no-rebase origin ブランチ名作業途中の内容をまだコミットしたくない場合は、git stashを使って一時的に退避する方法もあります。ただし、初心者のうちは無理に使わず、意味の分かる単位でコミットしてからpullするほうが管理しやすいでしょう。
バックアップブランチを作る方法
統合前の状態を残しておきたい場合は、次のようにバックアップブランチを作成できます。
git branch backup-ブランチ名このコマンドは、現在のコミットを指すバックアップ用の目印を作ります。現在の作業ブランチが切り替わるわけではありません。
バックアップできたことを確認するには、次のコマンドを使用します。
git branchやってはいけない対処
プッシュできないからといって、意味を理解しないまま強制プッシュするのは危険です。
git push --force強制プッシュをすると、GitHub側にあるほかの人の変更や、別の環境で作成したコミットを消してしまう可能性があります。
特別な理由がない限り、まずはGitHub側の変更をpullで取り込み、必要に応じて競合を解決してから通常のpushを行いましょう。
まとめ
今回プッシュできなかった原因は、GitHub側とローカル側の両方に新しいコミットがあり、変更履歴が分岐していたことでした。
次のコマンドでGitHub側の変更をmerge方式で取り込み、両方の変更を保持できました。
git pull --no-rebase origin ブランチ名また、VS Codeの「出力」に表示されるgit configやgit for-each-refは、VS CodeがGitの状態を確認するために実行しているコマンドです。[info]であれば、基本的にはエラーではありません。
同じトラブルを防ぐために、作業開始時には次の流れを習慣にします。
git switch ブランチ名
git pull --no-rebase origin ブランチ名Gitのエラーは難しく見えますが、多くの場合は大切な変更を守るために処理を止めています。
焦って強制プッシュせず、ローカルとGitHubのどちらに変更があるのかを確認してから対応することが重要です。
