3-2. GitHub/GitLabでのチーム開発フロー

このセクションで学ぶこと

ローカルリポジトリとリモートリポジトリの関係
branch を切って作業し、Pull Request / Merge Request で統合する流れ
レビューの役割と、指摘への対応のしかた
チーム開発で安全に進めるためのルールと、間違えたときの戻し方

1. なぜチーム開発にはルールが必要なのか

1 人で書いているときは、自分の頭の中だけで変更理由を管理できるように見える。
しかしチーム開発では、次のような問題が起きやすい。

誰が何を変えたのか分からない
他の人の変更を上書きしてしまう
まだ完成していない変更が main に混ざる
問題が起きても、どの変更を疑うべきか分からない

そのため GitHub や GitLab を使う実務では、変更を branch に分け、レビューを経て main へ取り込む という流れが一般的である。

main は共有の安定ライン
   ↑
直接壊さず、別 branch で作業してから戻す

この流れにすると、レビュー前に差分を確認しやすくなり、問題があっても影響範囲を小さくできる。

2. ローカルリポジトリとリモートリポジトリ

Git では、自分の PC 上の履歴と、GitHub/GitLab 上の共有履歴を分けて考える。

自分のPC（ローカル）  <-- fetch / pull -->  GitHub・GitLab（リモート）
        \--------------------------------->  push

用語	意味
ローカルリポジトリ	自分の PC 上にある Git の履歴
リモートリポジトリ	GitHub / GitLab 上などにある共有用の履歴
`origin`	代表的なリモート名

よく使うコマンド

コマンド	役割
`git clone <url>`	リモートを手元へ複製する
`git fetch origin`	リモートの最新履歴を取得するが、自分の作業はまだ変えない
`git pull --ff-only`	リモートの変更を取り込み、履歴が素直につながるときだけ更新する
`git push`	ローカルの commit をリモートへ送る

`fetch` と `pull` の違い

初心者が混同しやすいのが fetch と pull である。

fetch：取り寄せるだけ
pull：取り寄せて、自分の branch へ反映する

特に main を更新するときは、git pull --ff-only を使うと、意図しない merge commit を作りにくい。もし --ff-only が失敗しても、まだ壊したわけではない。
まず git status と git --no-pager log --oneline --graph --all を見て、どの branch がどこを指しているか確認しよう。

3. 典型的なチーム開発フロー

GitHub では Pull Request（PR）、GitLab では Merge Request（MR）と呼ぶ。
名前は違っても、「変更を main へ取り込む前にレビューしてもらう仕組み」という点は同じである。

基本の流れ

1. リポジトリを clone する
2. main を最新にする
3. 作業用 branch を作る
4. 変更して commit する
5. branch を push する
6. PR / MR を作る
7. レビューを受ける
8. 必要なら追加修正して push する
9. merge する
10. main を更新する

コマンドの例

git clone <repository-url>
cd <project-directory>
git switch main
git pull --ff-only
git switch -c feature/update-readme

branch で作業したあとは、通常次のように push する。

git push -u origin feature/update-readme

-u を付けると、次回以降は git push だけで同じリモート branch へ送りやすくなる。

なぜ `main` に直接 commit しないのか

理由はシンプルで、main は多くの場合 チーム全体が信頼する基準線 だからである。

直接 main に commit すると、

途中の作業がそのまま共有される
レビュー前に混ざってしまう
問題が起きたときに切り分けしづらい

そのため、まず feature branch で安全に進め、確認が終わったら main に戻すのが基本になる。

4. Pull Request / Merge Request の役割

PR / MR は、単に「マージしてください」と頼む場所ではない。
変更の意図・差分・確認方法を共有するための窓口 である。

PR / MR に書くとよい内容

項目	例
何を変えたか	README にセットアップ手順を追加
なぜ変えたか	初回起動で迷う人が多かったため
どう確認したか	ローカルで手順を再実行して確認
まだ気になる点	文言の表現はレビューで相談したい

小さな PR のほうがよい理由

1 つの PR に多くの変更を詰め込みすぎると、レビューする側も変更意図を追いにくくなる。

見やすい PR
- 1 つの目的
- 少数ファイル
- 明確な確認手順

見にくい PR
- UI変更
- API変更
- リファクタ
- バグ修正
を全部まとめる

レビューしやすい PR は、結果的に修正も早くなり、品質も上がりやすい。

5. コードレビューは何を見るのか

レビューは「相手を責める場」ではなく、コードの品質と影響範囲を一緒に確認する場 である。

よく見られる観点は次の通りである。

仕様どおりに動くか
バグや副作用がないか
変更範囲が目的に対して大きすぎないか
命名や構造が分かりやすいか
テストや確認が十分か

指摘を受けたときの考え方

レビューコメントを受けたら、まず「コードを良くするための材料」と考える。

意図が伝わっていないなら補足する
修正すべきなら追加 commit を作る
分からない指摘はそのままにせず質問する

実務では、レビューで分からないことを聞けること も大切なスキルである。

レビュー後の修正

PR を出したあとに修正が必要になっても、同じ branch に commit を積み増して git push すればよい。

git add README.md
git commit -m "Clarify setup steps"
git push

これにより、レビューの会話を保ちながら改善を続けられる。

6. チーム開発で安全に進めるルール

第 3 章では、まず次のルールを基本として覚えるとよい。

ルール1：作業前に `main` を最新にする

git switch main
git pull --ff-only

古い main から branch を作ると、あとで不要な差分や conflict が増えやすい。

ルール2：作業は branch で行う

git switch -c feature/login-form

作業を隔離しておけば、問題があっても main への影響を防ぎやすい。

ルール3：push 前に状態を見る

git status
git --no-pager diff
git --no-pager log --oneline --graph --all

「何を送ろうとしているのか」を見ずに push しないことが重要である。

ルール4：共有 branch の取消しは `git revert` を優先する

もし main に誤った変更が入ってしまったら、まず考えるべきなのは git revert である。

git revert <commit>

履歴を書き換えるよりも、何を取り消したかが見える形で残る ため、安全で説明もしやすい。

git pull --ff-only や git merge --ff-only が途中で止まった場合も、すぐに別の強いコマンドを重ねないことが大切である。
まず git status と git --no-pager log --oneline --graph --all で状況を確認し、「何も壊れていない状態で止まっている」ことを確かめてから次を考える。

ルール5：共有 branch では履歴の書き換えに慎重になる

実務では push --force や履歴書き換えが必要になる場面もあるが、初心者の段階ではまず次を徹底するとよい。

main では安易に履歴を書き換えない
まず fetch・status・log で状況を確認する
取り消しは revert で考える

「強く直す」より「安全に戻す」を優先することで、事故を小さくしやすい。

7. merge 後にやること

PR / MR が merge されたら、それで終わりではない。
手元の main も最新にし、次の作業に備える。

git switch main
git pull --ff-only

必要なら、役目を終えた feature branch を削除することもあるが、まずは「main を最新に戻す」ことを習慣にするとよい。

まとめ

キーワード	説明
ローカルリポジトリ	自分の PC 上の Git 履歴
リモートリポジトリ	GitHub / GitLab 上の共有履歴
`git clone`	リモートを手元へ複製する
`git fetch`	リモートの情報を取得するが、手元にはまだ反映しない
`git pull --ff-only`	安全寄りにリモート変更を取り込む
`git push`	自分の commit を共有先へ送る
Pull Request / Merge Request	merge 前に差分と意図を確認する仕組み
レビュー	品質・影響範囲・確認方法を一緒に見る活動
feature branch	`main` から分離して安全に作業する branch
`git revert`	共有履歴を壊さず変更を打ち消す方法

次のステップ

演習問題に取り組んで、チーム開発フローを安全な練習用リポジトリで再現しよう。

第3章を終えたら、4-1. 変数・型・制御フロー・関数へ進もう。