※ChatGPTを使用して記事を作成しています。
「ちょっとの修正だからブランチ切らなくていいよね」
「push する前に pull すればいいだけでしょ」
そんな軽い気持ちが、後に数人を巻き込んだ“Git地獄”の入り口だったとは──
当時の僕は知る由もありませんでした。
あの時のプロジェクト
あれは、2012年頃。Androidアプリ開発にも少しずつ慣れてきた頃で、一般ユーザ向けのアプリを4人のチームで開発していました。
当時はまだ Gitフロー も浸透しておらず、全員が同じブランチ（今でいう main）を直接触って開発するのが当たり前。
しかも、誰も “merge conflict”という言葉に慣れていない時代 でした。
CIもなければ、コードレビューもしていませんでした。
「ローカルでビルド通ったらpushしてOK」くらいのノリ。
まさに、今考えれば“クラシック地雷原”だったわけです。
サボったブランチ運用、始まりの合図
僕の担当は「商品検索」機能。
他のメンバーは「ログイン」「帳票出力」「GPS記録」などを分担。
この時点では特に問題なく、開発は順調に見えました。
しかし、ある日僕はブランチを切るのをやめました。
理由はこうです。
- 「今回はちょっとしたUIの調整だけ」
- 「ブランチ作るほどでもないでしょ」
- 「push前にpullすれば衝突しないよ」
これが すべての悲劇の始まり でした。
地雷その1：pullしてmerge地獄
翌日、僕が何気なく git pull をした瞬間。
Auto-merging SearchActivity.java
CONFLICT (content): Merge conflict in SearchActivity.java
Automatic merge failed; fix conflicts and then commit the result.画面が真っ赤になりました。
しかもそのファイルには、他のメンバーが昨日加えた処理がごちゃごちゃに入っている。
「自分が何を変更したのか」「どれが他人の修正なのか」が一目でわからず、git status を見ても混乱が深まるばかり。
正直、手が震えました。
地雷その2：消えたコード
恐る恐る conflict を解消したあと、意気揚々と push。
が、数時間後──メンバーから連絡が来ます。
「あれ？〇〇さん、昨日の修正消えてません？」
「俺のGPSログが無くなってる…」
そうです。
僕の手動mergeで、他メンバーの重要なコードが消えていたのです。
しかも、完全に気づかずにpushしていた…。
地雷その3：Revert地獄＆巻き戻しの嵐
慌ててGitのログを追って、git revert を試みます。
でも、どこからどこまでが僕のミスで、どのコードが「消された正しい処理」なのかがもう分からない。
結果、プロジェクトは 半日以上ビルドが通らない状態 に。
最終的に、Gitをよく知っていた外部の先輩エンジニアに泣きついて、git reflog から履歴を辿ってなんとか救出。
でも、チームの信頼は少しだけ崩れました。
「この人のpushは危険」という扱いを受けたこと、今でも覚えています。
僕が学んだ教訓
あの事件から、僕は Gitと真剣に向き合うようになりました。
以下のルールは、今でも自分に課しています。
🛡 ブランチは「必ず」切る
- 修正が1行でも、絶対に個人ブランチを使う
- プルリクを通すことで、第三者レビューが必ず入る
🛡 pullは必ずcommit後に行う
- 作業中にpullしない
- 中途半端な状態でマージすると、混乱の元
🛡 conflictを恐れない・丁寧に対処する
- 誰のどんな修正なのかを把握してからmerge
- 不明な点があればチームに聞くことを躊躇しない
🛡 Gitの履歴操作に慣れておく
reflog、stash、cherry-pickなどの使い方を学んでおく- 「何かあっても戻せる」安心感は大きい
失敗してよかったと思えるまでに
あの時は本当に冷や汗ものでしたが、今振り返れば
「失敗しておいてよかった」と思えるようになりました。
なぜなら、あの失敗がなければ今の自分のGit運用スタイルは生まれていなかったからです。
現代のチーム開発では、Gitの扱いはマナーであり、信頼のベース。
「Gitは信頼のインフラ」
この言葉を、僕は実体験として理解しています。
最後に
みなさんも、
「ちょっとの修正だから大丈夫」
「自分だけの作業だから問題ない」
そう思ってバージョン管理を雑に扱っていませんか？
その“ちょっとした油断”が、チーム全体を巻き込むトラブルに発展することもあります。
ぜひ、自分自身のGit運用を見直してみてください。
失敗する前に気づけたら、それが一番の成功です。
