📢 1. はじめに
はじめまして！
私は入社前、学校で約半年間プログラミングを学んでいました。当時はひたすら個人制作に励んでいたのですが、実はソースコードの管理は自分のパソコン内（ローカル環境）だけで完結させていました。
そのため、GitやGitHubは「名前は聞いたことがあるけれど、使い方はさっぱり……」という、実質未経験の状態で現在の開発現場に飛び込むことになりました。
そして入社後、私が速攻でぶち当たった大きな壁が、Git/GitHubを使った「チーム開発」です。
本記事では、個人開発の感覚のまま現場に入った私が、入社直後に直面したGitの失敗談（コンフリクト）と、それを心強いサポートツールであるGitHub Copilot（Chat機能）を有効活用してどのように乗り越えたか、その等身大の実体験をお届けします。
「現場のGit運用、難しすぎて冷や汗が出る……」と不安に思っている初学者の方の参考になれば嬉しいです！
💻 2. 「Gitって何？」レベルで挑んだ現場のリアル
入社してすぐに、先輩からこう指示を受けました。
「じゃあ、このリポジトリからクローンして、作業用のブランチを切って進めてね」
当時の私の頭の中は完全に「……？」です。
学校での個人開発であれば、コードを書き換えて上書き保存すればそれで終わりでした。もし失敗しても、エディタの Ctrl + Z（元に戻す）で引き返せばいい、くらいの感覚だったのです。
しかし、プロの現場における「チーム開発」は、「他人のコードと自分のコードがリアルタイムで混ざり合う世界」でした。
自分が書いたコードを共有の場所に反映させる（Pushする）という一連の流れ自体が、未経験の私にとっては「一歩間違えたら、先輩たちが苦労して書いた大切なコードを自分が消し去ってしまうのではないか……」という、とてつもない恐怖との戦いでした。
⚠️ 3. 恐怖のコンフリクト。最新状態を知らずにフリーズした話
入社して間もないある日、ついにその時がやってきました。
私に任されたのは、ある機能の開発業務です。
自分なりに実装を終えた後、レビューでの指摘をもとに修正を加え、「よし、これで大丈夫。あとはこの修正が正しく動いているかを確認するためのJUnitテストを作ろう！」と、テスト用のJavaファイル（〜Test.java）を修正しました。
無事にローカルでテストが通ることを確認し、意気揚々とPushしようとしたその時、画面に見慣れない不穏な文字が表示されました。
「Conflict（競合）」
「え、何これ？ テストコードを壊しちゃった……？」と、頭の中が真っ白になりました。
慌ててテストファイルを開くと、そこには学校の個人開発では見たこともない謎の記号が、大切なテストコードの間にびっしりと並んでいました。
<<<<<<< HEAD
@Test
void 自分が追加したテストメソッド() {
...
}
=======
@Test
void 先輩が追加したテストメソッド() {
...
}
>>>>>>> main
■ なぜこれが起きてしまったのか？
原因は、チーム開発における超・基本である「作業を始める前に、リモート（origin）から最新のコードを引っ張ってくる（pullする）」というルールや手順自体を、私がそもそも全く知らなかったことでした。
個人開発の感覚しか持っていなかった私は、「複数人が同じファイルを同時に書き換えていて、それがリアルタイムで更新されていく」というチーム開発の仕組みが全くイメージできていなかったのです。
JUnitのテストファイルは、他のメンバーも同時に新しい機能のテストケースを追加することが多い、まさに「激戦区」です。先輩がすでに最新のテストコードを反映させていたにもかかわらず、私が古い状態のファイルをベースに自分のテストを追加してしまったため、Gitが「どっちのコードが正しいの？」と混乱してしまったのです。
■ 当時の私の絶望
当時の私は、以下のダブルパンチで完全にフリーズしてしまいました。
- 「画面の謎の記号」をどう消して、どのコマンドを打てば解決できるのか分からない
- 本体の修正内容を踏まえて、どちらのテストコードを「正」として残すべきかの判断がつかない
自力で適当にコマンドを打って、先輩たちが書いた大事なテストを消し去ってしまうのが一番怖かったため、パソコンの前でしばらく冷や汗を流していました。
🚀 4. 解決アプローチ：GitHub Copilot（AI）を活用した自走と解消
コマンドも分からない、どちらのテストコードを「正」として残すべき（あるいは両方必要なのか）の判断もつかない……。
自力で適当に触ってコードを壊すのが一番怖かったため、私はまず先輩に現状を報告し、「このコンフリクト、どちらのコードを正として残すべきでしょうか？」とビジネス上の仕様を確認しました。
先輩からは「今回はどちらのテストも必要だから、両方の変更を取り込む形でマージしてね」と、進むべき正しい方向性を教えていただくことができました。
方向性は決まったものの、問題は「具体的にファイルのどの部分をどう修正し、どのコマンドを打てばいいのか」です。そこで大活躍してくれたのが、開発環境（VS Code）の横にいつも控えているGitHub Copilot（Chat機能）でした。
私はコンフリクトしているコードを提示しながら、チャット欄にこう問いかけました。
💬 私：
「JUnitのテストファイルでコンフリクトが発生しました。先輩から『両方のテストを残してマージしてほしい』と指示をいただいたのですが、この画面のどこを修正すればいいですか？また、解消に向けた具体的な手順も教えてください」
すると、GitHub Copilotは驚くほど丁寧に、ステップ・バイ・ステップで導いてくれました。
-
修正箇所の特定
画面上の<<<<<<< HEADや=======などの記号に囲まれた部分のうち、どこが自分の変更点で、どこが先輩の変更点なのかを明示。 -
具体的な修正方法
今回の指示通り「両方を残す」ために、エディタ上でどうコードを整理すべきか（またはVS Codeの「両方の変更を取り込む」機能を使うか）を具体的に提示。 -
解消後のコマンド手順
ファイルの修正が終わった後に打つべき、一連のコマンド（git add .➔git commit）の手順の案内。
AIが目の前のコードの「どこを直せばいいか」をピンポイントで教えてくれたおかげで、私は迷うことなく、安全にテストコードを修正することができました。
指示された手順通りに作業を終え、コマンドを実行することで、無事に初めてのコンフリクトを解消することができたのです。
📝 5. この経験から得た教訓とまとめ
今回の「コンフリクト事件」を通じて、私はチーム開発において欠かせない3つの大切な教訓を得ることができました。
① 作業開始時の「最新化」を習慣にする
自分一人で書いているのではないという意識を常に持ち、作業を始める前や定期的なタイミングで必ずリモート（origin）から最新のコードを取り込む（pullする）こと。これがチーム開発の平穏を守る「第一歩」だと身をもって学びました。
② 人（先輩）とAI（GitHub Copilot）の役割を分担する
今回の一番の学びは、「役割分担」の重要性です。
- 仕様の判断（どっちのコードを正とするか）： 先輩に確認する
- 実作業のサポート（コードの修正手順）： AI（GitHub Copilot）にサポートしてもらう
この進め方こそが、周囲の時間を奪いすぎずに最速で自走できるベストプラクティスだと気づけました。
③ トラブルを恐れず、仕組みを理解するヒントにする
入社前の私は、Gitに対して「難しそう、怖い」という苦手意識しかありませんでした。しかし、今回のように仕組みを正しく理解し、便利なツールを味方につけることで、トラブルは「成長のチャンス」に変えられるのだと確信しました。
🔑 今回の振り返り
入社直後は毎日が新しいことの連続で冷や汗をかくことも多いですが、今回のように「先輩方の知恵」と「AIの力」を掛け合わせながら、一歩ずつ確実に成長していきたいと思います。
最後まで読んでいただき、ありがとうございました！