Gitの基本コマンドを覚えても、チーム開発では「どのブランチから作業を始めるか」「featureとfixをどう分けるか」「どこまで確認してプルリクエストを出すか」で迷うことがあります。
この記事では、Git初学者やチーム開発に参加したばかりの方に向けて、作業ブランチの作成からレビュー依頼までを整理します。Gitの操作、GitHub上の手順、チームで決める運用ルールを分けながら、変更を小さくまとめて共有する流れを確認しましょう。
Gitブランチ運用の基本と作業前に確認すること
ブランチ・コミット・プルリクエストの役割を整理する
ブランチは、作業の履歴を分けて進めるための仕組みです。作業用のブランチを作ると、統合先のブランチを直接進めずに変更をコミットできます。Gitでは、ブランチ名が特定のコミットを指し、そのブランチでコミットするたびに指す先が進みます。
| 用語 | 役割 | 区別したいこと |
|---|---|---|
| ブランチ | 作業の履歴を分ける | 作成しただけではGitHubに共有されない |
| コミット | 選んだ変更をローカルの履歴へ記録する | ファイルの保存やpushとは別の操作 |
| push | コミットやブランチの情報をリモートへ送る | 通常、作業ブランチのpushだけではmainへ統合されない |
| プルリクエスト（PR） | 変更の取り込みを提案し、レビューする | Gitそのもののコマンドではなく、GitHubなどが提供する仕組み |
基本の流れは、作業ブランチを作る、編集する、コミットする、pushする、PRでレビューを依頼する、という順序です。マージは、その変更を統合先へ取り込む段階に当たります。
分岐元・マージ先・チームのルールを確認する
作業前に、READMEやCONTRIBUTINGなどの開発手順を確認します。分岐元は作業を始める基準、マージ先は完成した変更を取り込む先です。両方がmainとは限らず、開発用やリリース用のブランチを使う場合もあります。
- 今回の作業は、どのブランチから分岐してどこへマージするか
- ブランチ名・コミットメッセージ・PRタイトルに規約があるか
- 必要なテスト、レビュー担当、承認数が決まっているか
- マージ方法と、誰がマージするかが決まっているか
ブランチ名を自由に付けられることと、その名前がチームの運用に合うことは別です。既存のPRも参考になりますが、判断が分かれる場合は担当者に確認してから作業を始めます。
feature・fixの分け方とブランチの命名例
機能追加と不具合修正を目的で分ける
feature/は機能追加、fix/は不具合修正を表す命名例です。Gitがこの接頭辞によって動作を変えるわけではなく、GitHubがすべてのリポジトリに要求する名前でもありません。人が作業の目的を読み取るための規約として使います。
たとえば、検索機能がない画面に検索欄を追加するならfeature、検索条件が空のときに仕様と異なる結果になる問題を直すならfixが候補です。変更した行数ではなく、何を実現する作業なのかで判断します。
feature/add-search・fix/search-emptyのように変更内容を表す
接頭辞の後ろには、対象と変更内容が伝わる短い名前を付けます。以下は、作業目的に合わせた命名例です。
| 作業目的 | ブランチ名の例 |
|---|---|
| 検索機能を追加する | feature/add-search |
| 検索条件が空の場合の不具合を修正する | fix/search-empty |
| 検索結果に並び替えを追加する | feature/search-sort |
| 課題番号123の検索不具合を修正する | fix/123-search-empty |
workやupdateだけでは、一覧から目的を判断しにくくなります。小文字の英数字とハイフンを中心にすると表記をそろえやすいですが、課題番号の位置や略語の使い方はチームの規約を優先してください。
命名に迷う変更はチームの規約と作業目的を確認する
ドキュメント修正、依存関係の更新、内部構造の整理などは、featureとfixだけでは分類しにくい場合があります。チームによってはdocs/、chore/、refactor/などを使いますが、分類はチームの規約に従ってください。
たとえば、性能改善が新しい要件への対応なのか、既存の性能要件を満たさない不具合の修正なのかで、作業の説明は変わります。名前に迷ったら、まず課題の期待する状態を一文で書き、その目的に合う分類を確認しましょう。
ブランチを作成・切替して変更をpushする流れ
ここでは、ローカルにmainがあり、originのmainを基準に検索機能を追加する例を使います。コマンドはリポジトリ内で、一つずつ結果を確認して実行する想定です。途中でエラーや予想外の差分が出たら、その状態を確認してから先へ進めます。
現在のブランチと未コミットの変更を確認する
git status
git branch --show-currentgit statusでは、現在のブランチに加え、ステージ済み・未ステージ・未追跡のファイルを確認できます。git branch --show-currentは現在のブランチ名を表示します。名前が表示されない場合は、ブランチから離れた状態の可能性があるため、そのまま作業を進めず状態を確認してください。
未コミットの変更があるなら、それがどの作業に属するかを整理します。今回の例では、前の作業を適切なブランチへコミットするか、必要に応じて退避し、未コミットの変更がない状態から始めます。切替を通すためだけに変更を削除しないようにしましょう。
リモートの情報を取得して分岐元をそろえる
git fetch origin
git switch main
git log --oneline origin/main..main
git merge --ff-only origin/maingit fetch originはリモートの情報を取得し、通常のclone構成ではorigin/mainなどのリモート追跡ブランチを更新します。fetchだけでは、作業中のブランチへ変更は統合されません。また、取得に失敗した場合、手元のorigin/mainを最新として扱わないでください。
mainへ切り替えた後のgit log --oneline origin/main..mainは、origin/mainにはないローカルmain側のコミットを確認する指定です。出力がある場合は、この例の前提から外れるため、次のmergeへ進まず、そのコミットの扱いを確認します。
git merge --ff-only origin/mainは、履歴を分岐させずに先へ進められる場合だけmainを更新します。履歴が分岐していれば失敗するため、その場で強制的に合わせず相談してください。ローカル独自のコミットがなく、この更新に成功すれば、取得時点のorigin/mainを基準に作業を始められます。
作業ブランチを作成し既存ブランチへ切り替える
分岐元を確認できたら、作業ブランチを作成します。以下の-cは、現在のコミットを起点に新しいブランチを作り、そのブランチへ切り替える指定です。
git switch -c feature/add-search別の日に既存のローカルブランチで作業を再開するときは、作成を表す-cを付けません。
git switch feature/add-searchgit switchが利用できるGit環境を前提にしています。コマンドが認識されない場合は、利用中のGitとチームの案内を確認してください。ブランチ名が既に存在するエラーと、コマンド自体が利用できないエラーは分けて考えます。
変更を選んでコミットし作業ブランチをpushする
編集後は、変更を確認してからコミット対象をステージします。ステージは、次のコミットに含める内容を選ぶ場所です。以下はJavaプロジェクトの例です。パスは実際に変更したファイルへ置き換えてください。
git status
git diff
git add src/main/java/com/example/SearchService.java
git add src/test/java/com/example/SearchServiceTest.java
git diff --cached
git commit -m "検索機能と単体テストを追加"
git status
git push -u origin feature/add-searchgit diffは追跡済みファイルの未ステージ差分、git diff --cachedはステージ済みの差分を確認します。未追跡ファイルの内容は通常のgit diffには出ないため、git statusの一覧とファイル内容も確認してください。既にステージされた変更があれば、それもコミット対象になります。
初回pushの-uは、ローカルブランチの上流としてリモート側のブランチを設定します。pushされるのはコミット済みの内容であり、未コミットの編集は共有されません。pushが拒否された場合は、権限やリモート側の更新を確認し、強制pushで解決しようとしないでください。
レビューしやすい単位で変更とPRを小さく分ける
一つの目的に必要な実装・テスト・説明をまとめる
PRを小さくするとは、行数を減らすために必要なテストを外すことではありません。「このPRで何ができるようになるか」「どの不具合が直るか」を一つの目的として説明できる範囲にまとめます。
検索条件が空の場合の不具合修正なら、条件判定の変更、再発を防ぐテスト、必要な仕様説明を一つのPRへ含めます。一方、別画面の表示修正は独立して確認できるなら別PRに分けます。レビュー担当者が、変更の意図から確認結果までを追える単位が目安です。
無関係な整形やリファクタリングを混ぜない
数行の修正と同時にファイル全体を整形すると、動作に関わる差分が見つけにくくなります。変更した箇所に必要な整形は行いつつ、無関係なファイルの整形、名前の変更、共通処理の整理は別の作業にできないか検討します。
改行コードや文字コードの違いで、ファイル全体が変更として表示されることもあります。保存時の自動整形を含め、プロジェクトの設定を先に確認しましょう。Eclipseの整形操作を確認したい場合は、次の記事が補足になります。
変更同士が依存するときは分割方法を相談する
検索機能を追加するために共通部品の変更が必要な場合など、単純には切り離せない作業もあります。共通部品の変更だけでビルド・テストが成立し、独立した目的を説明できるなら、先にそのPRをレビューする方法が候補になります。
分割すると一時的に動かない状態になる場合は、行数だけを理由に分けないようにします。依存関係、レビューの順序、取り込み後に後続ブランチを更新する方法を相談してください。他の作業ブランチから分岐すると、その未マージの変更もPRに含まれ得る点に注意が必要です。
プルリクエスト前の確認チェックリスト
マージ先に対する差分とコミットを確認する
git statusで未コミットの変更がなくても、PRに不要な変更が含まれていないとは限りません。作業ブランチにいることを確認し、マージ先を取得してから、コミット済みの変更全体を確認します。以下はマージ先がmainの場合です。
git status
git fetch origin
git diff --stat origin/main...HEAD
git diff origin/main...HEAD
git log --oneline origin/main..HEADHEADは、ここでは作業ブランチの現在のコミットです。git diff origin/main...HEADの三つの点は、両者の共通祖先を基準に、作業ブランチ側で積み上げた差分を見る指定です。GitHubのPRで確認する変更範囲を把握する助けになりますが、push前のローカルコミットはGitHub側には表示されません。
git log origin/main..HEADの二つの点は、作業ブランチ側にはあり、origin/main側にはないコミットを列挙する指定です。diffの三つの点とは用途が違います。知らないコミットが含まれる場合は、分岐元やマージ先の選択を見直します。
これらはコミット同士の比較なので、未コミットの編集は含みません。作業ツリーの確認とPR対象の確認を両方行い、最後にGitHub上の差分も確認しましょう。
秘密情報・不要ファイル・意図しない整形差分を確認する
- パスワード、APIキー、トークン、秘密鍵などが含まれていないか
- 個人情報や実データを含むログ、画面キャプチャ、テストデータがないか
- 一時ファイル、ビルド成果物、個人用の設定が混ざっていないか
- 不要なデバッグ出力や、変更と関係のない整形差分がないか
.gitignoreへ追加しても、既に追跡されているファイルや過去のコミットから内容が消えるわけではありません。また、秘密情報を追加した後に削除した場合、最終差分では見えなくても途中のコミットに残ることがあります。共有するコミットの内容も確認してください。
秘密情報をpushしてしまった場合は、ファイルを削除するだけで完了にしないでください。チームの対応手順に従って連絡し、該当する認証情報の失効・再発行を進めます。履歴の扱いは影響範囲を確認してから決めます。
必要なビルドとテストを実行し未確認事項を記録する
READMEや開発手順で指定されたビルド・テストを実行します。Javaプロジェクトでも、使うビルドツール、Wrapper、プロファイル、外部サービスの有無によって手順が変わるため、プロジェクトのコマンドを優先してください。
不具合修正なら、問題が起きる条件と修正後の期待動作を確認します。検索条件の修正なら、通常の入力に加え、空文字など今回変更した境界条件も対象です。ビルド成功と、必要なテストが実際に実行されたことは分けて確認します。
PRには実行したコマンド、結果、必要に応じて環境条件を記録します。DBへ接続できず結合テストを実行していないなら、その範囲と理由を書きます。「未実行」「実行したが失敗」「実行して成功」を区別し、確認していない項目を成功扱いにしないことが大切です。
PRの目的・変更内容・確認結果・レビュー観点を準備する
レビュー担当者が最初に知りたいのは、なぜ変更が必要で、何が変わるのかです。リポジトリにPRテンプレートがあればそれを使い、次の情報をそろえます。
| 項目 | 記載する内容 |
|---|---|
| 目的 | 解決する課題と期待する動作。関連するIssueがあれば示す |
| 変更内容 | 実装・テスト・説明の変更と、影響する範囲 |
| 確認結果 | 実行した手順と結果、未実行の項目と理由 |
| レビュー観点 | 特に確認してほしい仕様判断や互換性への影響 |
たとえば、「検索処理を修正」よりも「空の検索条件を未指定として扱うよう判定を変更」の方が、確認対象を伝えやすくなります。PRの説明は、確定している仕様と実際に得られた確認結果に基づいて書きましょう。
GitHubでPRを作成してレビューにつなげる
baseとcompareを確認してPRを作成する
作業ブランチをpushしたら、GitHubの対象リポジトリでPR作成画面を開きます。基本の入口は「Pull requests」から「New pull request」へ進む流れです。画面の表示が異なる場合も、比較するブランチの向きを確認する点は共通です。
| 項目 | 意味 | この記事の例 |
|---|---|---|
| base | 変更を取り込む先 | main |
| compare | 変更を提案する側 | feature/add-search |
baseとcompareを選び、コミットとファイル差分が意図どおりであることを確認してから、タイトルと説明を入力します。最後にPRを作成し、チームのルールに従ってレビュー担当者やラベルを設定します。既定で選択されたbaseが、今回の正しいマージ先とは限りません。
作業途中の共有ではDraft PRを検討する
設計の方向性を早めに相談したい場合や、実装途中の状況を共有したい場合は、利用できる環境ならDraft PRが候補になります。説明には、完成している範囲、残っている作業、今の段階で意見がほしい点を書きます。
レビューを受けられる状態になったら、通常のレビュー待ちへ切り替えて担当者に伝えます。Draftは完成前であることを示す機能であり、秘密情報を含めてよいという意味でも、CIが必ず停止するという意味でもありません。CIの実行条件は設定を確認してください。
CI結果とレビュー指摘を確認して追加変更を反映する
PR作成後は、設定されているチェックの実行状況と結果を確認します。CIが実行されるタイミング、対象ブランチ、必須チェック、マージ制限はリポジトリ設定によって異なります。チェックが表示されないことを、テスト成功と判断しないようにしましょう。
指摘に対応するときは、同じ作業ブランチで修正し、差分とテストを確認して追加コミットをpushします。同じリモートブランチを参照するPRには、その変更が反映されます。修正内容をコメントで伝え、仕様判断への指摘なら、意図を確認してから対応します。
追加変更の後は、最新のコミットに対するCI結果とレビュー状態を確認します。ビルドやテストの自動化の仕組みを学びたい場合は、次の記事でCI/CDの基本を補足できます。
ブランチ運用で初学者が注意したいこと
切替できないときは未コミットの変更を確認する
ブランチ切替で変更が上書きされる可能性があると、Gitが操作を止めることがあります。まずgit statusと差分を確認し、編集中の内容がどの作業に属するかを判断します。適切なブランチでコミットするか、一時退避する方法を検討してください。
未コミットの変更があっても切替できる場合はありますが、その変更が切替先へ持ち越されることもあります。「切替できたので、変更は元のブランチに保存された」とは考えないでください。stashで退避する場合も、通常の指定では未追跡ファイルが含まれないため、退避対象を確認する必要があります。
コンフリクトは変更の意図を確認して解消する
コンフリクトは、複数の変更をGitが自動で統合できない状態です。同じ箇所を別々に変更した場合だけでなく、ファイルの削除と編集が重なった場合などにも起こります。まず、どの操作で発生し、どのファイルが対象になっているかを確認します。
解消では、片方を機械的に採用するのではなく、両方の変更が何を実現しようとしているかを読み取ります。判断できなければ変更者へ確認し、統合後の内容をテストしてください。エディタの「現在の変更」「受信した変更」といった表示も、操作の文脈を確認して扱います。
修正後はコンフリクトの印が残っていないこととgit statusを確認し、実行中の操作に合った手順で完了させます。mergeとrebaseでは続行手順が異なるため、別の操作向けのコマンドを混ぜないようにしましょう。
共有ブランチの履歴変更や強制pushは事前に相談する
コミットの修正や並べ替えは、既に共有したコミットとは異なる履歴を作る場合があります。他の人がその履歴を基に作業していると、手元との整合を取り直す必要が生じます。共有済みブランチの履歴を変更する前に、チームのルールと利用者を確認してください。
pushの拒否は、リモート側に自分がまだ取り込んでいない変更があるなど、確認が必要な状態を示していることがあります。強制pushを一般的な解決策にしないことが大切です。レビュー中の修正は、チームの指定がなければ追加コミットで共有する方法から検討します。
マージ完了を確認して作業ブランチを片付ける
PRが意図したマージ先へ取り込まれたことを確認し、追加作業や他の人の利用がなければ、チームのルールに従って作業ブランチを片付けます。PRが閉じられただけでは、マージ済みとは限りません。
ローカルに未コミットの変更がなく、mainに独自のコミットもないことを確認したうえで、次は通常の履歴関係でマージ済みになったブランチを削除する例です。
git switch main
git fetch origin
git merge --ff-only origin/main
git branch -d feature/add-searchgit branch -dは、削除対象のブランチが上流ブランチにマージ済みかを確認します。上流が設定されていない場合は、現在のHEADを基準に判定します。この記事の例ではgit push -uでorigin/feature/add-searchを上流に設定しているため、削除に成功してもmainへの取り込みを確認できたことにはなりません。削除前にPRの状態、取り込まれた内容、未共有のコミットの有無を確認してください。mainを基準に判定する場合は、squashなどのマージ方法によって、GitHubでは取り込み済みでも削除を拒否されることがあります。拒否されたら、すぐに強制削除せず状態を確認してください。
ローカルブランチの削除と、GitHub側のブランチ削除は別です。リモート側はGitHubの削除操作などを使い、他の作業が参照していないことを確認して整理します。次の作業は、更新した正しい分岐元から新しいブランチを作成しましょう。
まとめ
Gitのブランチ運用では、作業前に分岐元・マージ先・チームのルールを確認することが出発点です。featureとfixは作業目的を伝える命名規約の例であり、機能追加なのか不具合修正なのかを説明できる名前にします。
ブランチを作ったら、一つの目的に必要な実装・テスト・説明をまとめてコミットし、pushします。PR前には、未コミットの変更だけでなく、マージ先に対する差分とコミット、秘密情報や不要ファイル、ビルドとテストの結果まで確認してください。
GitHubではbaseとcompareを確かめ、目的・変更内容・確認結果・レビュー観点を添えて共有します。未確認事項も明記し、追加修正後のCIとレビュー状態を確認してから、チームの手順に沿ってマージとブランチの整理へ進めましょう。
コメント