Git は『個人ツール』ではなく『チーム合意の道具』
Git は強力なバージョン管理ですが、チーム開発では「ブランチ戦略」「コミット作法」「PR ルール」「トラブル対処」の合意が必須です。本記事では、Git をチームで安全に使う実務作法を編集部の視点で整理します。GitHub Actions学習、GitHubポートフォリオの作り方 もご参考に。
主要なブランチ戦略
(1) GitHub Flow：main + feature ブランチ。シンプル。(2) Git Flow：develop + release + hotfix。複雑だが大規模リリースに有効。(3) Trunk Based Development：main 中心・短命ブランチ。CD と相性が良い。(4) 環境別ブランチ：staging/production を分離。(5) 選び方：リリース頻度・チーム規模・自動化レベルで決まる。テスト戦略の基礎 もご参考に。
コミットメッセージの作法
(1) Conventional Commits：feat / fix / docs / chore 等。(2) 動詞から始める：「○○を○○する」。(3) 1コミット1テーマ：複数まとめない。(4) なぜを書く：何より理由を残す。(5) 関連 Issue を引用：履歴が辿れる。Claude CodeのSkills活用 もご参考に（規約自動化）。
PR（Pull Request）の作法
(1) 小さく分ける：レビューしやすい単位に。(2) 説明を丁寧に：背景・変更点・テスト。(3) セルフレビュー：提出前に自分で見直す。(4) スクリーンショット・動画：UI 変更は視覚的に。(5) CI を通してから出す：壊れた状態を出さない。ジュニアからシニアエンジニアへの昇進 もご参考に。
コードレビューの文化
(1) 建設的に：人格でなくコードを評価。(2) 具体的に：「ここをこう変えると」。(3) 質問形式の活用：「これはどうですか？」。(4) 承認の基準を明示：何があれば LGTM か。(5) 迅速に：レビュー待ちは生産性の敵。チームと組織を動かす技術 もご参考に。
典型的なトラブル対処
(1) コンフリクト：rebase or merge で解消。(2) 誤コミット：reset / revert。(3) 誤 push：履歴を変えない revert を優先。(4) force push の影響：チームへの事前合意。(5) 大きな履歴整理：interactive rebase。「force push は最終手段」というルールを持つチームが多いです。SREへの転身ガイド もご参考に（運用安全性）。
大きなリポジトリでの工夫
(1) monorepo の選択：管理負荷とトレードオフ。(2) gitignore の整備：不要なファイルを除外。(3) git LFS：大きなバイナリの管理。(4) 履歴の縮約：必要に応じて squash。(5) シークレットスキャン：誤コミット防止。セキュリティエンジニアへの転身ガイド もご参考に。
失敗しがちなパターン
(1) main へ直接 push：レビューを通さない。(2) 大きすぎる PR：レビューが形骸化。(3) 長く生きる branch：merge コンフリクトが爆発。(4) 履歴の改ざん：force push でチームに迷惑。(5) シークレット混入：取り返しが付かない事故。対策は、(1)PR 必須、(2)PR を分割、(3)短命 branch、(4)force push 抑制、(5)シークレットスキャン、です。IT・Web業界の職種完全マップ もご活用ください。