実務の開発フローとは？Issue・ブランチ・PR・レビュー・マージを解説

「インターンで『PRを出してください』と言われたけど、何のことかわからなかった」
「GitHubは使えるけど、チームで開発するときの流れが全然イメージできない」
「ブランチとかマージとか、言葉は知ってるけど実務でどう使うのかわからない」

プログラミングを学んでいる大学生が最初につまずくのが、「個人での学習」と「実務でのチーム開発」の間にある大きなギャップです。

Progateで学んだり、個人でポートフォリオを作ったりすることと、企業のエンジニアが日常的にやっていることは、使う技術こそ似ていても、「開発の進め方」がまったく異なります。

この記事では、エンジニアの実務開発がどんな流れで進んでいくのかを、Issue・ブランチ・PR（プルリクエスト）・レビュー・マージという一連の流れに沿って、大学生にも理解できるよう丁寧に解説します。

"知っている"を"経験した"に。3ヶ月でチーム開発を実践！

• 受講生数1.2万人突破！満足度は95.5%
• Issue・PR・レビューを実際のチーム開発で体験
• 3ヶ月で"即戦力に近い"インターン対応力が身につく

まずは無料説明会をのぞいてみる

なぜチーム開発には「フロー」が必要なのか

個人開発との最大の違いは「複数人が同時に動く」こと

個人でポートフォリオを作るとき、あなたは一人でコードを書いて、一人でGitHubに上げます。誰かと同時に同じファイルを編集することはないし、自分の変更が他の人の作業を壊す心配もありません。

チーム開発ではそうはいきません。5人・10人・それ以上のエンジニアが同時に異なる機能を開発しています。誰かがメインのコードを変更すれば、他の全員に影響が出ます。誰かのバグが本番環境（実際のユーザーが使うサービス）に入り込めば、サービス全体が止まります。

この「複数人が同時に動く」という状況を安全に管理するために、実務のチーム開発には決まった「流れ（フロー）」があります。

実務の開発で使う主なツール

開発フローを理解する前に、実務でよく使われるツールを把握しておきましょう。

• GitHub / GitLab：コードを保管・管理するクラウドサービス。チームで変更履歴を共有できる
• Git：自分のPCで変更を管理するツール。GitHubと連携して使う
• Slack / Teams：チームのコミュニケーションツール。開発の連絡はここで行われることが多い
• Jira / Notion / Linear：タスク管理ツール。誰が何をやっているかを管理する

この記事では主にGitHubを使った開発フローを説明します。GitLabなど別のサービスでも、基本的な流れは同じです。

実務の開発フロー全体像

実務の開発は、大きく以下の6つのステップで進みます。

1. Issue：「何を作るか・何を直すか」を決める
2. ブランチ作成：変更作業用の「作業スペース」を作る
3. 実装：コードを書く
4. PR（プルリクエスト）作成：「この変更を取り込んでほしい」と申請する
5. レビュー：他のエンジニアが変更内容を確認する
6. マージ：変更を本体に取り込む

それぞれを詳しく見ていきましょう。

STEP1：Issue｜「何をやるか」を言語化する

Issueとは何か

Issueとは、「やるべきこと」を記録するチケットです。バグの報告・新機能の要望・改善提案など、開発に関するあらゆるタスクがIssueとして管理されます。

GitHubにはIssue機能が標準で備わっており、チームのメンバーが「このバグを修正する必要がある」「この機能を追加したい」と思ったときに、Issueを作って記録します。

テックエイドの解説によると、プルリクエストの出発点はIssueで管理されたタスクであり、「誰がいつ・何のために変更したのか」を後から追跡できることがチーム開発の重要な要素とされています。

出典：株式会社テックエイド「プルリクエストとは？コードレビューの流れを初心者向けに解説」（2026年5月20日）

Issueに書くべき内容

良いIssueは、作業をする人が見るだけで「何を・なぜ・どのくらいの規模で」やればいいかわかる内容になっています。典型的なIssueには以下のような情報が含まれます。

• タイトル：やること・問題の概要（例：「ログインページでパスワードリセットのリンクが壊れている」）
• 概要：詳細な説明と背景
• 再現手順（バグの場合）：どうすれば問題が起きるか
• 期待する結果：修正後にどうなるべきか
• 担当者・期日：誰がいつまでにやるか

実務では新しい開発はほぼ必ずIssueから始まります。「なんとなくコードを書き始める」という進め方はしません。

STEP2：ブランチ作成｜「作業スペース」を分ける

ブランチとは何か、なぜ必要なのか

Issueが決まったら、次にブランチを作成します。ブランチとは、メインのコードに影響を与えずに作業できる「分岐した作業スペース」のことです。

料理に例えると、「本番のお皿（mainブランチ）」をそのまま使うのではなく、「試作用の別皿（featureブランチ）」で料理を作って、完成したら本番のお皿に移す、というイメージです。

mainブランチ（またはmasterブランチ）は、常に動く状態の本番コードが入っている場所です。ここに直接変更を加えると、失敗した場合に本番サービスが壊れるリスクがあります。そのためチーム開発では、mainブランチへの直接コミットを禁止しているチームがほとんどです。

ブランチの命名ルール

実務ではブランチに名前をつけるとき、チームで決めたルールに従います。よくある命名パターンは以下の通りです。

feature/ログイン機能の追加         # 新機能
fix/パスワードリセットのバグ修正   # バグ修正
refactor/ユーザー認証の整理       # リファクタリング

「feature/」「fix/」「refactor/」のようなプレフィックス（接頭辞）をつけることで、そのブランチが何のための作業なのかが一目でわかります。新卒・インターンのエンジニアがよくやるミスが「ブランチ名を適当につける」ことです。後で何のブランチかわからなくなるため、命名には具体性が重要です。

STEP3：実装｜コードを書く

実務での「コードを書く」とは

ブランチを作ったら、Issueに書かれた内容に従って実装を進めます。ここは個人開発と大きく変わらない部分ですが、実務ならではのポイントがいくつかあります。

こまめにコミットすることが鉄則です。「全部できてからまとめてコミット」は、万が一何か問題が起きたときに戻れる地点がなくなるためNGです。「ログイン画面のUIを追加」「バリデーション処理を追加」のように、意味のある単位でこまめにコミットする習慣が重要です。

コミットメッセージは「何をしたか」を具体的に書きます。「修正」「変更」「fix」だけのコミットメッセージは、後から履歴を見たときに何をしたか分かりません。「ログインフォームのバリデーションエラー表示を追加」のように具体的に書くのが実務のルールです。

実装中に詰まったら早めに相談します。個人開発では自分だけの問題ですが、チーム開発ではあなたの遅れが他のメンバーに影響します。「詰まったまま半日沈黙」よりも「30分で詰まったことを報告して相談する」方がチームにとって望ましい行動です。

STEP4：PR（プルリクエスト）作成｜「確認してください」の申請

PRとは何か

実装が終わったら、PR（プルリクエスト）を作成します。PRとは、「自分のブランチの変更をmainブランチに取り込んでほしい」という申請のことです。

「プルリクエスト」という名前は、「mainブランチに対して、自分の変更をPull（引っ張ってきて）してほしいというRequest（依頼）」という意味から来ています。GitHubではPR、GitLabではMR（マージリクエスト）と呼ばれます。

良いPRの書き方

Qiitaで未経験エンジニアが「PR出してからレビューを受けて気づいたこと」として書いた記事では、PRで最も重要なのは「レビュアーへの配慮」だと述べられています。

「PRを作ること自体がゴールになっていた。マージ先のブランチは合っているか。余計な差分が含まれていないか。変更の意図が伝わるか。レビュワーが何を確認すればよいのか。そこまで深く考えられていなかった」

出典：Qiita「未経験エンジニアが3ヶ月目で学んだ、GitHubにおけるプルリクエスト・セルフレビュー入門2026」（2026年7月16日）

良いPRには以下のような情報が含まれます。

タイトル：変更の概要を一言で（例：「ログインページにパスワードリセット機能を追加 #123」）

概要：何を・なぜ変更したかの説明。関連するIssueのリンクも記載する

変更内容の詳細：主にどのファイルを・どう変えたかを箇条書きで説明

確認手順：レビュアーが実際に動作を確認するための手順

スクリーンショット（UIの変更がある場合）：Before/Afterの画像

PRの本文が充実しているほど、レビュアーがスムーズに確認できます。「PRを出す＝レビュアーへの仕事の依頼」という意識が重要です。

PR出す前のセルフレビュー

PRを出す前に、自分でも一度確認する「セルフレビュー」が実務では推奨されています。確認すべき主なポイントは以下の通りです。

• マージ先のブランチは正しいか（間違えてdevelopブランチではなくmainに出してしまう失敗は多い）
• 余計なファイルが差分に含まれていないか（デバッグ用のコードや.envファイルが混入していないか）
• コンソールエラーや警告が出ていないか
• テストが通るか
• コードのコメントやコミットメッセージが適切か

STEP5：レビュー｜他のエンジニアが確認する

レビューとは何か・なぜ重要なのか

PRが出されると、担当のエンジニア（レビュアー）が変更内容を確認します。これがコードレビューです。

テックエイドの解説では、コードレビューの役割として以下の3点が挙げられています。

「コードレビュー：別のエンジニアが変更内容を見て、バグや設計上の問題を事前に発見する。知識の共有：PRを通じて『誰がどこを変更したか』『なぜその実装にしたか』がチームで共有される。変更の記録：PRにはタイトルと説明を書くため、後から『あの機能をいつなぜ変更したか』を追いかけられる」

出典：株式会社テックエイド「プルリクエストとは？コードレビューの流れを初心者向けに解説」（2026年5月20日）

コードレビューは「バグを見つける作業」だけではありません。チーム全体でコードの内容・設計方針・変更の理由を共有する場でもあります。

レビューコメントの3種類

レビュアーは変更内容を確認しながら、コードの特定の行にコメントをつけることができます。実務でよく見られるレビューコメントは大きく3種類に分かれます。

Must（必須）：バグ・セキュリティ問題・設計上の問題など、必ず対応が必要な指摘です。これがある限りPRはマージされません。

Should（推奨）：対応が望ましいが必須ではない改善提案です。基本的には対応するのが礼儀ですが、対応しない場合は理由を返信します。

Nit / Optional（任意）：細かい好みの話や参考情報など、対応は作成者に任せる内容です。「nit:」や「[optional]」などのプレフィックスをつけて区別します。

指摘を受けたときの正しい対応

新卒・インターンのエンジニアがつまずきやすいのが、レビューコメントへの返し方です。実務では以下のような対応が期待されています。

コメントを全部読んでから対応します。コメントが複数ある場合、1つずつ返信しながら修正するのではなく、全体を把握してから修正を進めましょう。コメント同士が関連していることも多いためです。

修正した場合は「対応しました」と返信します。レビュアーは何が修正済みかをPR画面で確認します。修正したのに返信がないと、レビュアーが再確認するタイミングがわかりません。

理解できないコメントは質問します。「指摘された意味がわからない」「自分の実装の方が良いと思う理由がある」場合は、返信で質問・議論することが推奨されます。指摘を黙って受け入れるだけでなく、対話することが成長につながります。

STEP6：マージ｜変更を本体に取り込む

マージとは何か

レビュアーが「問題なし」と判断してApprove（承認）すると、いよいよマージが行われます。マージとは、featureブランチの変更をmainブランチに統合することです。

マージが完了すると、あなたが書いたコードがメインのコードベースに取り込まれます。チームメンバー全員の環境に、あなたの変更が反映されます。

マージ後にやること

マージが完了したら、以下の作業を行います。

使い終わったブランチを削除します。マージ済みのブランチは不要なため削除するのがルールです。GitHubではマージ後に「Delete branch」ボタンが表示され、ワンクリックで削除できます。

Issueをクローズします。そのIssueに対応するPRがマージされたら、Issueを「完了」としてクローズします。GitHubでは、PRの本文に「Closes #123」と書いておくと、マージ時に自動でIssueがクローズされます。

動作確認を行います。マージ後にステージング環境（本番の前段階の確認環境）や本番環境にデプロイされた後、意図通りに動作しているかを確認します。

実務での開発フロー全体を通して押さえるポイント

ここまでの6ステップを通じて、実務の開発フローの全体像がつかめたはずです。大学生・インターン生がこのフローに初めて触れるとき、特に意識してほしいポイントをまとめます。

実務で大切にすべき姿勢は、主に以下の3点です。

• 「作って出せば終わり」という感覚を捨てる
• コミュニケーションの量が品質を決める
• 失敗を恐れず、早めに相談する

「作って出せば終わり」という感覚を捨てる

Qiitaの記事でも紹介した通り、「PRを出すことがゴール」という意識は実務では通用しません。PR作成から始まるレビュー・修正・再レビューというサイクルまでが開発の一部です。マージされるまでが1つのタスクだという意識を持ちましょう。

コミュニケーションの量が品質を決める

コードレビューは、技術的なチェックの場でもあり、チームの暗黙知を共有する場でもあります。Qiitaの技術記事では「コードレビューをしないと、ただ目の前のタスクをこなしレビューを受ける一方通行の開発になってしまう」と指摘されています。

出典：Qiita「若手エンジニアのコードレビュー 〜斜め上のPRを見て学ぼう！〜」

レビューコメントへの返信を丁寧に行う、わからないことを積極的に質問するなど、コミュニケーションの質がチーム全体の開発品質に直結します。

失敗を恐れず、早めに相談する

実務のエンジニアは皆、最初はこの流れを知りませんでした。わからなくて当然です。大切なのは「詰まったまま抱え込まないこと」です。実務では「30分考えてわからなければ相談する」「レビューコメントの意味がわからなければ質問する」という文化が根付いているチームが多いです。

就活・インターンでこの知識をどう活かすか

この開発フローを理解した上で就活・インターンに臨むと、以下の場面で具体的なアドバンテージが生まれます。

面接でのアピールとして「GitHubを使った開発フロー（Issue・ブランチ・PR・レビュー・マージ）を理解しています」と伝えられるだけで、「即戦力に近い学生」という印象を与えられます。

ポートフォリオの質向上として、個人開発でも意図的にIssueを立てて・ブランチを切って・PRを作る流れで開発することで、「実務の開発スタイルを経験済み」という状態をGitHubのリポジトリで示せます。

インターンでの立ち上がりの早さとして、初日から「PRを出してレビューをもらう」という流れがわかっていれば、教わる時間を最小限にして即実戦に入れます。

まとめ｜実務の開発フローは「チームで安全にコードを変える仕組み」

今回の内容を振り返ります。

• Issue：「何を・なぜやるか」を言語化したチケット。開発は必ずここから始まる
• ブランチ作成：mainへの影響を避けるための「作業スペース」を分離する
• 実装：こまめなコミット・具体的なコミットメッセージが実務のマナー
• PR作成：「変更の意図・確認手順・差分の説明」をレビュアーに伝える申請。セルフレビューを忘れずに
• レビュー：Must/Should/Nitの3種類のコメントがある。指摘は黙って受け入れるより対話することが重要
• マージ：Approve後にmainへ統合。ブランチ削除・Issueクローズ・動作確認まで行う

ここまで読んで、Issue・ブランチ・PR・レビュー・マージという流れを頭では理解できたはずです。しかし、この記事の冒頭で触れた通り、「個人での学習」と「実務でのチーム開発」の間には大きなギャップがあります。そのギャップを埋める一番の方法は、知識としてではなく、実際にチームで体験することです。

大学生限定プログラミングスクール GeekSalon（ギークサロン）では、カリキュラムの中でGitHubを使ったチーム開発を実際に経験できます。Issueを立て、ブランチを切り、PRを作成し、仲間からレビューを受けてマージする——この記事で紹介した一連の流れを、3ヶ月のチーム開発の中で実践的に体得できます。

「面接でGitHubを使った開発フローを説明できます」ではなく「実際にチームで開発した経験があります」と言えることは、インターンや就活で大きなアドバンテージになります。

受講生数は1.2万人を突破、満足度は95.5%。「知っている」から「経験した」への一歩を踏み出したい方は、まずは無料説明会をのぞいてみてください。

"知っている"を"経験した"に。3ヶ月でチーム開発を実践！

• 受講生数1.2万人突破！満足度は95.5%
• Issue・PR・レビューを実際のチーム開発で体験
• 3ヶ月で"即戦力に近い"インターン対応力が身につく

まずは無料説明会をのぞいてみる