「Gitは使える。でもチーム開発は初めて」なあなたへ…
Gitの操作には慣れてきたけど、「チームで使うときって、どんなルールを決めればいいの？」そんな疑問を持ったことはありませんか？
この記事では、チーム開発でよく使われるGitのルールをカテゴリごとに一覧でまとめました。
どれも実務で役立つものばかり。さらに、各ルールにはちょっとだけ説明もつけて、すぐに使えるようにしています。
なぜルールが必要なの？
Gitは自由度が高いぶん、ルールがないと人によってやり方がバラバラになりやすいです。チームで開発を進めるとなると、それこそ個々人が自分のルールを適用してしまってバラバラの管理状態になります。
- ブランチ名が読めない
- コミット履歴がカオス
- PRが放置される
- いつの間にか本番が壊れてる…
こうしたトラブルは、ちょっとしたルールを決めておくだけで防げます。みんなが迷わず気持ちよく開発できる。そのために、ルールは“チームの共通言語”として必要なんです。
Gitチーム運用ルール一覧
実際にGitですぐにでも適用できるルールを上げていきます。自分のチームやプロジェクトにあったものを採用してみてください。優先度もつけています。迷ったらとりあえず★★★は採用してみようぐらいの気持ちで問題ありません。
優先度マークの意味
- ★★★…超重要：全チームで推奨。まず決めるべきルール
- ★★☆…推奨：中規模以上、または運用が落ち着いてきたら導入推奨
- ★☆☆…補助的：環境やチームによっては不要だが知っておくと便利
命名・ブランチルール
| 優先度 | 内容 | 補足説明 |
|---|---|---|
| ★★★ | main への直接 push 禁止 | 保護ブランチを設定し、必ずPR経由でマージすることで事故を防ぐ |
| ★★★ | ブランチ命名ルールの統一 （例： feature/taro-login） | 開発者がどんな作業をしているか一目でわかり、管理もしやすくなる |
| ★★☆ | fix/, docs/, hotfix/ など目的別プレフィックス | 種類を分けることで作業の意図が明確になり、レビュー・管理もスムーズ |
| ★☆☆ | 使い終わったブランチは削除 （GitHub上も含む） | 放置されたブランチが増えるのを防ぎ、リポジトリを整理された状態に保てる |
コミットルール
| 優先度 | 内容 | 補足説明 |
|---|---|---|
| ★★★ | コミットメッセージに種類を付ける （ feat, fixなど） | 一覧で見たときに意図がわかりやすく、履歴も読みやすくなる |
| ★★★ | コミット粒度の目安を共有 （例：1PRあたり3〜10コミット） | コミットしすぎ・少なすぎを防ぎ、適切な粒度を意識できる |
| ★★☆ | 英語か日本語かを統一する | 表記が混在すると見づらくなるため、チームで揃える |
| ★★☆ | fixup!, squash! を使って後から整理する | コミットをあとでまとめるときに便利で、きれいな履歴を保てる |
PR・レビュー運用ルール
| 優先度 | 内容 | 補足説明 |
|---|---|---|
| ★★★ | PRテンプレートを全員が使う | 説明の抜け漏れを防ぎ、レビューの質を安定させる |
| ★★★ | PRは1つの目的（機能）につき1つ作る | 差分が明確になり、レビュアーの負担が軽くなる |
| ★★★ | マージ方法を統一 （例：Squash Merge） | 履歴をシンプルに保ち、後から変更を追いやすくなる |
| ★★☆ | コメントに nit: や must: をつけて優先度を明示する | 修正の重要度がわかりやすくなり、コミュニケーションの無駄が減る |
| ★★☆ | LGTMだけでなく感想・観点も添える | どこを見たかが伝わり、安心感・学びにもつながる |
| ★☆☆ | PR作成時にSlack等に通知する | PRの放置防止、進捗の見える化に役立つ |
履歴管理・運用戦略
| 優先度 | 内容 | 補足説明 |
|---|---|---|
| ★★★ | git rebase の前に pull を行う（ git pull --rebase） | 最新の履歴と合わせてからrebaseすることで衝突や事故を防ぐ |
| ★★★ | main へマージする前にCIが通っていることを確認する | 動作保証されたコードだけが本番に入るようにする |
| ★☆☆ | マージ後にタグ（v1.0.0 など）を付ける | リリースやバグ調査時にバージョンを特定しやすくなる |
CI/CD・自動チェック
| 優先度 | 内容 | 補足説明 |
|---|---|---|
| ★★★ | PR作成時にCIが必ず動くようにする | 未検証のコードを本番に入れないための最低限のセーフティネット |
| ★★☆ | Linter / Formatter をCIで自動実行する | スタイルや記法の統一が自動化され、手動レビューの負担を減らせる |
| ★★☆ | commit前に pre-commit hook でLintをかける | ローカルでのエラー混入を防ぎ、CI失敗の手戻りを減らせる |
| ★☆☆ | .editorconfig を導入してエディタ設定の違いを吸収 | 複数環境でもインデントなどが揃い、見やすさ・整合性を保てる |
ドキュメント・共有
| 優先度 | 内容 | 補足説明 |
|---|---|---|
| ★★★ | README.md に起動手順やルールを記載 | 新メンバーが自走できるようになり、質問・手戻りが減る |
| ★★☆ | CONTRIBUTING.md に開発ルールを書く | PR・コミットの書き方などの共通理解が進む |
| ★☆☆ | CHANGELOG.md を用意して変更履歴を残す | 何がいつ・誰によって変わったのかを後から確認できる |
| ★☆☆ | .git-blame-ignore-revs を使って整形だけの履歴を除外 | Lintやフォーマット変更が blame を邪魔しないようにできる |
トラブル防止・注意喚起
| 優先度 | 内容 | 補足説明 |
|---|---|---|
| ★★★ | force push は原則禁止 | 履歴破壊・共有トラブルの原因になりやすい。やむを得ない場合は周知必須 |
| ★★☆ | .env など秘密ファイルは .gitignore に追加 | APIキーやパスワードなどの漏洩を防ぐための基本 |
| ★☆☆ | 秘密情報を誤ってpushした際の削除方法を共有 | git filter-repo などでの完全削除手順をチーム内で周知 |
チーム運営・習慣づくり
| 優先度 | 内容 | 補足説明 |
|---|---|---|
| ★★★ | 毎朝または夕方に「PR確認タイム」を設ける | PRが放置されにくくなり、レビューの流れがスムーズになる |
| ★★☆ | レビュー依頼・完了はSlackなどで通知 | 情報の行き違いを防ぎ、作業の可視化にもつながる |
| ★★☆ | #git-help のような相談用チャンネルを設ける | トラブルや疑問の共有がしやすくなる |
| ★☆☆ | 月1でGit運用ルールの棚卸し会を開く | 運用ルールのアップデートと振り返りができる良い機会になる |
まとめ
ルールを作る目的は「縛る」ことではなく、チーム全員が迷わず、快適に開発できる状態を作ることです。まずはできそうなもの・気になったものから、少しずつ取り入れてみてください。この記事に挙げたルールはほんの一部でしかありません。これらのルールは運用していく中で、チームに合わせて柔軟に育てていけばOKです。
