Git / GitHub

チーム開発編

複数人でのGit運用

👤
1人
→
👥
チーム

ブランチ戦略・コードレビュー・保護ルール

この編の全体像

ゴール: チームでGitを使うときのルールと仕組みを理解し、混乱なく協力開発できるようになる

Section 1

なぜルールが必要か

1人開発との違いを理解
→ 問題意識を持つ

Section 2

ブランチ戦略

GitHub Flow / Git Flow
→ mainを壊さず安全に開発する方法を知る

Section 3

命名規則

ブランチ名・コミットメッセージ
→ チーム内の共通言語を作る

Section 4

コードレビュー

PR・レビュー・マージ
→ 品質を保ちながら知識を共有する仕組み

Section 5

CODEOWNERS & 保護ブランチ

自動レビュアー・ブランチ保護ルール
→ 自動でルールを強制する安全装置

Section 6

チーム開発の1日

朝のpullから夕方のマージまで
→ 実際の作業フローを体験する

なぜチーム開発にルールが必要か

👤 1人で開発する場合

  • 自由にコミット・プッシュできる
  • ブランチを切らなくても問題ない
  • コンフリクトは発生しない
  • 自分のペースで進められる

👥 チームで開発する場合

  • 同じファイルを同時に編集 → コンフリクト
  • 他人の変更を上書き → 作業消失
  • 何が変わったか分からない → 混乱
  • バグがどこで入ったか不明 → 原因追跡が困難

ルールを決めておけば、これらの問題を防げる

ブランチ戦略: GitHub Flow

シンプル・初心者向け
main
本番環境
→
feature branch
機能開発
→
Pull Request
レビュー依頼
→
merge to main
本番反映
GitHub Flow デモ

ブランチ戦略: Git Flow

大規模プロジェクト向け
main
本番リリース
develop
開発の統合先
feature/*
機能開発
release/*
リリース準備
hotfix/*
緊急修正

GitHub Flow を選ぶ場合

小〜中規模チーム
継続的デプロイ
シンプルさ重視

Git Flow を選ぶ場合

大規模チーム
バージョン管理が必要
リリースサイクルが長い

命名規則

ブランチ名の規則

feature/

新機能の開発
feature/add-login
feature/user-profile

bugfix/

バグの修正
bugfix/fix-header-layout
bugfix/login-validation

hotfix/

緊急の修正
hotfix/security-patch
hotfix/crash-on-startup

コミットメッセージの規則

Conventional Commits

feat: 新機能を追加
fix: バグを修正
docs: ドキュメント変更
style: コードスタイル修正
refactor: リファクタリング
test: テスト追加・修正
例:
feat: ユーザー登録フォームを追加
fix: メール送信時のエラーを修正

コードレビュー

コードレビューとは？

他のメンバーが書いたコードを確認し、
フィードバックを送るプロセス

なぜ必要か

  • バグの早期発見
  • コード品質の向上
  • 知識の共有・チーム学習
  • 一貫性のあるコードベース
Open feat: ログイン機能を追加
#42
Reviewers
● tanaka — レビュー待ち
T
tanaka commented 2 hours ago

パスワードのバリデーションを追加した方がよさそうです。
最低8文字のチェックはありますか？

✓ Approve ✗ Request changes

コードレビュー デモ

gh CLIでPR作成からマージまで
コードレビュー フロー

CODEOWNERS

自動レビュアー割り当て

CODEOWNERSとは？

特定のファイルやディレクトリに対して、自動的にレビュアーを割り当てる仕組み

  • PRを作ると自動でレビュー依頼が飛ぶ
  • 担当領域を明確にできる
  • レビュー漏れを防止できる
  • .github/CODEOWNERS に設置
.github/CODEOWNERS
# デフォルトのオーナー
* @team-lead
 
# フロントエンド
src/components/ @frontend-team
src/styles/ @frontend-team
 
# バックエンド
src/api/ @backend-team
src/database/ @db-admin
 
# インフラ・CI/CD
.github/ @devops-team
Dockerfile @devops-team
 
# ドキュメント
docs/ @tech-writer

Protected Branches

mainブランチを守る

何から守るのか？

  • レビューなしの直接マージ
  • CIテストが失敗した状態でのマージ
  • git push --force による履歴破壊
  • ブランチの誤った削除
Settings → Branches → Branch protection rules
main
✓
Require a pull request before merging
✓
Require approvals: 1
✓
Require status checks to pass
✓
CI / test suite
✓
Do not allow force pushes
✓
Do not allow deletions

Protected Branches デモ

直接プッシュは拒否される
ブランチ保護の動作

Collaborators & Permissions

アクセス権限の管理

リポジトリの権限レベル

Read

コードの閲覧・Issue作成
外部コントリビューター向け

Write

プッシュ・PR作成・マージ
開発メンバー向け

Admin

設定変更・メンバー管理
プロジェクトリーダー向け

Settings → Collaborators
Y
yamada
Owner
Admin
T
tanaka
Member
Write
S
suzuki
Member
Write
E
external-dev
Outside collaborator
Read

チーム開発の1日

日常のワークフロー
9:00
git pull origin main 最新のmainを取得してスタート
↓
9:05
git checkout -b feature/... 作業ブランチを作成
↓
9:10〜
コードを書く → commit → push こまめにコミット、適度にプッシュ
↓
16:00
gh pr create Pull Requestを作成してレビュー依頼
↓
17:00
レビュー → 修正 → Approve チームメンバーがコードをレビュー
↓
17:30
gh pr merge --squash mainにマージして完了！

まとめ — チーム開発のルール

ブランチ戦略

mainには直接コミットしない
feature branchで作業する

命名規則

feature/ bugfix/ hotfix/
feat: fix: docs:

コードレビュー

PRを通じてレビューを受ける
品質と知識共有を担保

ブランチ保護

レビュー必須・CI必須
force push禁止

CODEOWNERS

担当領域を明確化
自動レビュアー割り当て

権限管理

Read / Write / Admin
最小権限の原則

ルールを守ることで、チーム全員が安心して開発できる

Appendix: コマンドリファレンス

コマンド 説明
git checkout -b <branch> 新しいブランチを作成して切り替え
git checkout main mainブランチに切り替え
git add 変更をステージングエリアに追加
git commit -m "msg" ステージングした変更を履歴に記録
git push -u origin <branch> ブランチをリモートにプッシュ（上流設定付き）
git push ローカルの変更をリモートにプッシュ
git pull origin main mainブランチの最新変更を取得・統合
git reset HEAD~1 直前のコミットを取り消し（変更は残る）
gh pr create プルリクエストを作成（GitHub CLI）
gh pr edit --add-reviewer PRにレビュアーを追加
gh pr merge --squash PRをスカッシュマージ（コミットを1つにまとめて統合）
git push --force 強制プッシュ（履歴破壊の危険あり、非推奨）
1 / 15
← → キーで移動