USBメモリは何版まで進みましたか？

GitとGitHubを使っていない時代、大学生のグループレポートや会社の小規模チームでのプロジェクトは、通常このように進められていました：

Aさんが完成した レポート_v1.docx をLINEでBさんに送信。 Bさんはダウンロード後、2段落追加して レポート_v2_B修正.docx に改名しグループに送信。同時にCさんも レポート_v1.docx を修正し、レポート_v2_C追加.docx に改名して送信。最終的にリーダーのAさんは、デスクトップ上の十数個のファイル（レポート_最終版_本当に修正なし.docx 含む）を見ながら、2つのウィンドウを開き、目視で一行ずつ比較し、全員の修正を1つのファイルにコピペする羽目に。

この「USBメモリ/LINEファイル送信法」と呼ばれる協働スタイルは、プログラミングの世界では絶対に通用しません。コードの1つの句読点ミスでシステム全体が停止する可能性があるため、数千行のコードを目視で比較することは不可能です。

これが全世界のソフトウェア企業が、エンジニアに GitHubを唯一の協働プラットフォームとして使用することを強制している理由 です。

協働の核心概念：リモートリポジトリ (Remote) とローカル (Local)

GitHubの世界では、GitHubウェブサイト上にあるプロジェクトフォルダを 「リモートリポジトリ (Remote Repository)」 と呼び、通常デフォルト名は origin です。そして自分のノートPCにダウンロードしたフォルダを 「ローカルリポジトリ (Local Repository)」 と呼びます。

多人協働の黄金ルールはただ一つ： 「自分が書いたコードをプッシュ (Push) する前に、必ず、必ず、必ず同僚が書いた最新コードをプル (Pull) してください！」

コマンド実戦：PullとPushの日常的な二人舞

あなたと同僚の「小明」さんが一緒にVibe Tutorのウェブサイトを開発していると仮定します。このプロジェクトは既にGitHub上にあります。

シナリオ1：朝出社した時 最初にすべきことは、コードを書き始めることではありません。Cursorのターミナルを開き、次のコマンドを入力します： git pull origin main このコマンドの意味は：「GitHub (origin) のmainブランチから、小明さんが昨夜残業で書いた最新コードを全てダウンロードして、私のPCを更新してください」

シナリオ2：新機能を完成させ、帰宅準備する時 「ログイン機能」を完成させた場合、GitHubにアップロードする手順：

git add . (全ての変更をステージングエリアに追加)
git commit -m "会員ログイン機能完成" (変更履歴を記録)
git push origin main (履歴とコードをGitHubにプッシュ)

二人が「まずPull、次にコード修正、最後にPush」というサイクルを忠実に守れば、お互いのファイルを上書きすることなく、完璧に協力してソフトウェアを構築できます。

なぜコンフリクト (Conflict) が発生するのか？

完璧なユートピアでは、あなたと小明さんは常に異なるファイルを修正します。あなたは login.js を書き、小明さんは cart.js を書くので、干渉しません。

しかし現実は残酷です。火曜日の午後、あなたと小明さんが「同時に」 index.html (ホームページ) を開きます。あなたはホームページの10行目に「今すぐ購入」という赤いボタンを追加。小明さんは同じ10行目に「カートに追加」という青いボタンを追加。

小明さんが素早く午後3時に git push を実行。GitHubは青いボタンを完璧に受け取りました。午後4時、あなたは満足げに git push と入力し、帰宅準備。

すると、ターミナルに赤い文字が大量に表示されます： ! [rejected] main -> main (fetch first) hint: Updates were rejected because the remote contains work that you do not have locally.

このメッセージの平易な説明は：「GitHubはあなたのアップロードを拒否しました！GitHubには小明さんが書いた新しいコード（青いボタン）がありますが、あなたのPCにはありません。まずpullする必要があります！」

あなたは従順に git pull と入力します。すると、さらに大きな災害が発生し、ターミナルには再び目に痛い赤い文字が： CONFLICT (content): Merge conflict in index.html

正面突破！コンフリクト (Merge Conflict) 解決のVibeメソッド

コンフリクトに遭遇した時、初心者の最初の反応は通常：心拍数上昇、手のひら発汗、フォルダ全体を削除して再ダウンロードしたくなることです。深呼吸して、自分に言い聞かせてください：「コンフリクトはエンジニアの日常であり、Gitがお互いのファイル上書きを防ぐための安全機構です」

Gitがあなたと小明さんが「同じファイルの同じ行」を修正したことを検出すると、どちらが正しいか判断できないため、この決定権をあなたに委ねます。

ステップ1：コンフリクト発生ファイルを開く

Cursorで index.html ファイルを開きます。中には宇宙人が残したような記号が見えます：

<<<<<<< HEAD
<button class="bg-red-500">今すぐ購入</button>
=======
<button class="bg-blue-500">カートに追加</button>
>>>>>>> 1a2b3c4d... (小明さんのcommit)

<<<<<<< HEAD から ======= まで：あなたのPCにあるコード（赤いボタン）。
======= から >>>>>>> まで：GitHubからダウンロードした小明さんのコード（青いボタン）。

ステップ2：AIに判断を委ねる

以前は、エンジニアが手動で <<< 記号を削除する必要があり、誤って括弧を1つ多く削除するとコードが壊れました。しかしVibe Coding時代では、この「衝突現場」を選択し、Cmd+K (またはCtrl+K)を押して、次のプロンプトを入力できます：

【Gitコンフリクト解決プロンプト】 「ここでGitマージコンフリクトが発生しています。上は私が書いた赤い購入ボタン、下は同僚が書いた青いカートボタンです。両方のボタンを『保持』し、divコンテナ内に並べて配置し、ボタン間に少しスペースを空けてください。」

AIは瞬時に宇宙人記号を消去し、あなたと小明さんのコードを完璧に融合します：

<div class="flex gap-4">
  <button class="bg-red-500">今すぐ購入</button>
  <button class="bg-blue-500">カートに追加</button>
</div>

ステップ3：解決済みとしてマークしアップロード

コードが修正されたことを確認したら、ターミナルに戻り、Gitに衝突現場が解決されたことを伝えます：

git add index.html (このファイルのコンフリクトが解決されたことをGitに伝える)
git commit -m "小明さんとのindex.htmlボタンコンフリクトを解決"
git push origin main

おめでとうございます！あなたは新人エンジニアの自信を粉砕する可能性のある核爆弾を無事に解体しました。 Pull、Push、そして コンフリクト解決 という三大スキルを習得したことで、あなたは一流ソフトウェア企業で数十人のシニアエンジニアと協働する基本的な資格を得ました！

次章では、GitHubを活用して、あなた自身の輝かしいエンジニア専用履歴書を作成する方法を学びます。