女性向けエンジニアスクール
3秒でわかる
複数人で同じコードベースを育てる進め方。ブランチ運用とレビューの手順を決めて、他人の変更と自分の変更がぶつからないようにするのが中心になります。
もう少し詳しく
どういうものか
チーム開発は、ひとつのリポジトリを複数人で同時に触りながら機能を積み上げていく進め方です。技術そのものよりも、作業の分け方と合流のさせ方が主題になります。具体的には、誰がどの作業を持つかを Issue で見えるようにし、作業ごとにブランチを切り、Pull Request でレビューを受けてから本体に合流させる、という流れが標準的です。
なぜ必要か
ひとりで書いている間は、自分の頭の中にあるルールで済みます。人数が増えると、同じファイルを二人が同時に直す、片方の変更でもう片方が壊れる、何がリリース済みなのか誰も分からない、といった問題が一気に出ます。手順を決めるのは、これらを「起きてから直す」のではなく「起きにくい形にする」ためです。
具体例
機能追加ひとつぶんの流れは次のようになります。
git switch main
<a href="/glossary/git-pull" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">git pull</a> # 最新の本体に追いつく
git switch -c feat/login-form # 作業用ブランチを切る
# ここで編集する
git add .
git commit -m "ログイン<a href="/glossary/form" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">フォーム</a>を追加"
git <a href="/glossary/push" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">push</a> -u origin feat/login-form
# GitHub 上で Pull Request を作り、レビューを受けて main へマージ
git switch main
git pull
git branch -d feat/login-form # 済んだ枝は消すつまずきやすいところ
作業ブランチを長く生かしすぎると、合流のときに大量の衝突が出ます。数日で終わる大きさに切り、こまめに main を取り込むほうが結果的に速く終わります。
レビュー依頼の粒度も問題になりがちです。20 ファイルの変更をまとめて出すと、レビュアーは細かい指摘しかできません。ひとつの Pull Request にはひとつの目的だけを入れます。
レビューを人格の評価と受け取ってしまうのも、初めてのうちはよくあることです。指摘されているのはコードであって書いた人ではありません。逆にレビューする側は、「ここは何が起きるか読めなかった」のように、自分が分からなかった事実として書くと角が立ちません。
もうひとつ多いのが、main を直接編集してしまう事故です。ローカルで作業を始める前に、今どのブランチにいるかを確認する習慣が要ります。
似た用語との違い
| 語 | 指すもの |
|---|---|
| ブランチ | 本体から分けた作業用の枝 |
| Pull Request | 枝を本体へ合流させたいという依頼と、その議論の場 |
| マージ | 枝の変更を本体へ取り込む操作 |
| コンフリクト | 同じ箇所を両方が変えていて、機械では決められない状態 |
覚え方
「切る、書く、見てもらう、戻す」の 4 拍子です。どの現場でも呼び名が違うだけで、この形は変わりません。
