【Phase 2初日】VS CodeでGitエラーと格闘:何が起こっていたのか

Phase 2初日、VS CodeからGitHubにプッシュする際、様々なエラーに遭遇しました。当時は混乱しましたが、後から振り返って「何が起こっていたのか」を整理します。

※この記事はAIエージェント(Claude)の解説をもとに構成しています。


状況の整理

前提

GitHubには既にファイルがある(ブラウザでアップロードした青色版)

GitHub: index.html, style.css(青色のバージョン)

ローカル(PC)には修正版がある(VS Codeで編集した緑色版)

ローカル: index.html, style.css(緑色のバージョン)

Gitはこれらを「別々の歴史」と認識してしまった。


エラー1: src refspec main does not match any

実行したコマンド

git push -u origin main

エラーメッセージ

error: src refspec main does not match any
error: failed to push some refs to 'https://github.com/dondokoboy/profile.git'

原因

ローカルでGitの初期化(git init)はしたが、コミット(記録)がまだない状態だった。

プッシュするには、まず「何かを記録」する必要がある。

解決方法

git add .
git commit -m "色を緑系に変更、メッセージ文を修正"

コミットを作成してから、再度プッシュ。


エラー2: Author identity unknown

実行したコマンド

git commit -m "色を緑系に変更、メッセージ文を修正"

エラーメッセージ

Author identity unknown
*** Please tell me who you are.

原因

Gitに「あなたが誰か」を教えていなかった。

Gitは「誰がこの変更をしたのか」を記録するため、名前とメールアドレスが必要。

解決方法

git config --global user.email "your-email@example.com"
git config --global user.name "Pacho"

重要: この設定は一度だけで良い。次回からは不要。


エラー3: rejected - fetch first

実行したコマンド

git push -u origin main

エラーメッセージ

! [rejected]        main -> main (fetch first)
error: failed to push some refs
hint: Updates were rejected because the remote contains work that you do not have locally.

原因:歴史の不一致

これが最も複雑な問題でした。

GitHub側の歴史:
  commit A(ブラウザでアップロードした青色版)
  
ローカル側の歴史:
  commit B(VS Codeで作った緑色版)

GitHubは「commit A」という歴史を持っている。
ローカルは「commit B」という全く別の歴史を持っている。

Gitから見ると:

  • 「どっちが正しいの?」
  • 「両方を統合するの?上書きするの?」

判断できないのでエラー

試した解決方法1: pull(統合を試みる)

git pull origin main --allow-unrelated-histories

意味:

  • pull = GitHubからファイルを取得
  • --allow-unrelated-histories = 「関連のない歴史でも統合していいよ」

結果:コンフリクト(競合)

CONFLICT (add/add): Merge conflict in index.html
CONFLICT (add/add): Merge conflict in style.css

コンフリクトとは:

  • 同じファイルの同じ場所を、異なる内容で変更したとき
  • Gitが「どっちを採用すればいいか分からない」状態

最終的な解決方法:強制上書き

git rebase --abort  # コンフリクト解決を中止
git push -u origin main --force  # 強制的に上書き

--forceの意味:

  • 「GitHubの歴史を無視して、ローカルので上書きしろ」

結果:

GitHub: commit A(青色) → 削除
       ↓
GitHub: commit B(緑色) ← ローカルので上書き

成功!


なぜこんなことになったのか

本来の正しい流れ

1. GitHubでリポジトリ作成(空っぽ)
   ↓
2. ローカルでGit初期化
   ↓
3. ローカルでファイル作成
   ↓
4. commit → push
   ↓
5. GitHub Pagesで公開

この流れなら、歴史は1本だけ。

今回の流れ(イレギュラー)

1. GitHubでリポジトリ作成
   ↓
2. ブラウザでファイルをアップロード ← ここで歴史A
   ↓
3. ローカルでGit初期化
   ↓
4. ローカルでファイル編集
   ↓
5. commit → push ← ここで歴史Bを作ろうとした
   ↓
6. 衝突!

原因:

  • 最初にブラウザでアップロードしたことで「歴史A」が作られた
  • ローカルで新しく作った「歴史B」と矛盾した

用語の整理

Git(ギット)

バージョン管理システム。「いつ、誰が、何を変更したか」を記録する。

コミット(commit)

変更を記録すること。「この時点のスナップショット」を保存。

プッシュ(push)

ローカルの記録をGitHubにアップロード。

プル(pull)

GitHubの記録をローカルにダウンロード。

ブランチ(branch)

開発の「枝」。今回はmainという名前のブランチ。

コンフリクト(conflict / 競合)

同じファイルの同じ場所を、異なる内容で変更したとき。Gitが「どっちを採用すればいいか分からない」状態。

–force(強制)

「問答無用で上書きしろ」というコマンド。

危険:GitHubの内容が消える可能性がある。

今回は問題なかった(どちらも自分のファイルだから)。


全エラーの流れ(時系列)

1. git push
   → エラー1: コミットがない
   
2. git commit
   → エラー2: ユーザー情報がない
   
3. ユーザー情報設定 → git commit成功
   
4. git push
   → エラー3: GitHubとローカルの歴史が違う
   
5. git pull(統合を試みる)
   → コンフリクト発生
   
6. git push --force(強制上書き)
   → 成功!

次回からはこうなる

今回、すべての初期設定が完了したので、次回からは超簡単

# 1. ファイルを編集(VS Code)
# 2. 以下の3つのコマンドだけ

git add .                        # 変更を記録対象に
git commit -m "色を赤に変更"      # 記録を作成
git push                         # GitHubにアップロード

これだけ!


今回学んだ教訓

良かったこと

✅ Gitの基本的な流れを体験できた
✅ エラーの解決方法を学べた
✅ 実際の開発で起こる問題を経験できた
--forceという危険なコマンドの使い方を知った

次回から気をつけること

⚠️ 最初からローカルで作業する
⚠️ ブラウザでアップロードしない
⚠️ Git初期化 → commit → push の流れを守る


まとめ

今回起こったこと

  1. GitHubとローカルで「別々の歴史」が作られた
  2. Gitが統合方法を判断できずエラー
  3. 強制上書きで解決

次回からは

  • 初期設定済みなので簡単
  • add → commit → push の3ステップだけ

エラーは学びのチャンス。

今回の経験で、Gitの仕組みを深く理解できました。


※この記事の技術的な解説は、AIエージェント(Claude)によるものです。


カテゴリ: 学習計画, Phase 2
タグ:
スラッグ:

コメント