「mainに直コミット…だと…！？」未経験からGit運用を整えた話
未経験から1ヶ月でGit/GitHubを理解し、ある中〜大規模プロジェクトでGit運用設計とリードを担当した私が、現場で感じた違和感と実際のルール構築の経験を語ります。
😃 自己紹介
10年間レガシーな開発現場で勤め、Gitや共同開発プロセスを使わない環境から独学で勉強を始め、「現場経験ゼロ、Git/GitHubの知見は独学１ヶ月程度・・」という状態から実際に現場のルールを作る立場に立った一エンジニアの記録です。
😃「私はGit未経験ですが、プロジェクト開始まで勉強して使えるようにします！タグ打ちで使えるようにですね、わかりました！！」
↓１ヶ月後現場にて
チーフ「asさんはGitHubすごい詳しいから！GitHubのことは全部asさんに任せて大丈夫だから、みんなasさんに教えてもらって進めてね！」
メンバー「GitHubのことは完全にお任せになってしまいますが、リードお願いします！」
😃？？？(しかし、使えはするけど私は「実務未経験で１ヶ月勉強しただけの初心者」だなんてとても言える空気ではないし、こうなったらやるしかない・・・)
😯 mainに直接コミットがごっそり残ってる？
人生初のGitHubの共同開発で中〜大規模のプロジェクトに参加した際、GitHubを覧測してみると、mainブランチに直接コミットが連続している現場に出くわし衝撃を受けました。
本来、mainは「リリース状態を統一的に表す本線」として、緊急事態を除き、直接コミットやpushをするものではありません。(完全に個人で開発する場合は例外)
しかし現場の複数リポジトリを確認した所、mainへの直pushが常態化している作業フローに慎重さを覚えました。
📝 実際に設計したGit運用ルール
現場の実態を見た上で、Git未経験者が多数を占めるチームに対して、下記のような運用方針を設計しました：
-
mainブランチは絶対に触らない（直接のコミット・
push禁止） - Pull Requestの作成前に
mainへ切り替えてpull（リモートの最新を取得） -
コミットは一度行ったらやり直し禁止（
push前でも禁止。revertなど履歴を汚さず戻す方法もありますが、それも誤操作に繋がると思ったためやり直しは全面禁止にしました。） - Pull Requestマージ後は、ローカルとリモートのブランチを利用者自身で削除して、再生成する
- コンフリクト発生時は自分で解決しようとせず、私に報告するだけでOK
これだけ守れば、事故が起きずにチームが安心して開発できる。
それが、初心者チームを率いる自分の最大の責任だと考えました。そしてメンバー協力のもと、トラブルもなく安全なリポジトリ運用が実現しました。
なぜこの運用方針にしたのか？
Gitには、fetchとmergeを分ける運用や、rebase、commit --amendのような高度な履歴管理の手法もあります。
しかし、知識の段階や理解の精度によっては、むしろそれが事故や混乱の原因になると感じました。
だから私は、「正しさ」よりも「安全さ」「単純さ」を優先しました。
GUIユーザーに対しての配慮も設計に含めた
初心者のメンバーがなるべく簡単に操作できるよう、CLI派の私もVS CodeのGUIも覚えてGit操作を指導しました。
「必ずこの順番で、ここを押してからここを押します！そして次にここを押します！」という感じで手順を教えました。
GUIでも「今どのブランチにコミットされるか」が表示される箇所があり、 そこを指さしながら「ここを必ず確認してから、コミットしてください！！」と念を押して伝えていました。
こうすることで、ブランチの概念が理解できていなくても、mainへの直コミット事故を未然に防げるようにしました。
🤔 ブランチはなぜ削除しないといけないの？
- ブランチは「作業領域」であり、完了したら片付けるべき
- 同じ名前でもローカルとリモートは別物
- 残されたブランチは「何のための誰のコード？」と認識されず、終わった作業が放置される
- CIやコードレビューのコストサービスも消耗する
ブランチの消し忘れや「なぜ消すの？」といった疑問の声もあり、わかりやすく解説する試行錯誤も続けました。
結論：Gitを理解すると、チームの信頼性も範囲も変わる
自分を「本当の初心者」だと思っていた私の方が、現場のやり方に違和感を覚える日が来るなんて、まったく想像していませんでした。
でも、Gitを深く理解していくと、従来のなあなあな開発のこわさも、コードに対する信頼性も、使い方で変わると知りました。
これからZennでも、Git運用チーム設計や現場の違和感を記録していきます！
Discussion