第11回: チーム開発でのGit基本フロー — 個人作業のGitと実務のGitはどこが違うのか

章: 第4章: チーム開発の実務フロー

1人で使うGitと、チームで使うGitは目的が少し違う

ここまで見てきたGit操作は、主に「自分の変更を安全に管理する」ためのものでした。これは土台としてとても重要です。

しかし実務になると、Gitの役割はもう一段広がります。

チーム開発では、Gitは変更を記録する道具であると同時に、作業を分担し、レビューし、統合するための共通基盤になります。

つまり、「自分が困らないためのGit」から、「チーム全体が破綻しないためのGit」へ視点を広げる必要があります。

実務でよくある基本フロー

実際の開発では、次のような流れで作業することが多いです。

1. main から作業ブランチを切る

2. 変更を実装してコミットする

3. リモートへ push する

4. プルリクエストを作成する

5. レビューを受けて修正する

6. 問題なければ main へマージする

この流れを見るとわかる通り、実務のGitは commit や push で終わりません。その先に、他人が確認できる形で差分を見せる工程があります。

なぜブランチを分けるのか

ブランチを分ける理由は、単に作業を整理するためだけではありません。

• 未完成コードを本流へ直接入れないため
• レビュー単位を明確にするため
• 問題があった変更だけを追いやすくするため

たとえば、ログイン修正と記事画面修正が同じブランチに混ざっていると、レビューする側はかなり読みづらくなります。

実務では「コードが動くか」だけでなく、「差分が読みやすいか」も重要です。

チーム開発で意識したいこと

ここが、個人開発と実務の大きな違いです。

実務でありがちな失敗

• main に直接コミットしてしまう
• 無関係な変更を1つのブランチに混ぜる
• コミットメッセージが雑で履歴の意味が読めない
• レビュー前提の差分になっていない

このあたりは、Gitコマンドの知識不足というより、チームで使う前提の意識不足 で起きやすいです。

チェックポイント: 実務のGitは「保存」より「共有と統合」が中心だと捉えると、操作の意味がつながりやすくなります。

まとめ & 次のステップ

• チーム開発ではGitが作業分担と統合の基盤になる
• 実務では push の先にプルリクエストとレビューがある
• ブランチは未完成コードを本流へ直接入れないために重要
• 差分の読みやすさや履歴の意味も品質の一部
• 個人作業のGitから、チームのGitへ視点を広げる必要がある

次回はプルリクエストの基本を扱います。 なぜ多くの現場でプルリクエスト経由の開発をするのかを整理しましょう。