GitHub で機能開発を進める基本フロー

GitHub を使った開発では、いきなり main ブランチを編集するのではなく、作業用のブランチを作り、変更をコミットし、GitHub に push して、Pull Request（PR）でレビューを受けてから main にマージします。

このページでは、「プロフィール画面に自己紹介欄を追加する」という小さな機能開発を例に、ブランチ作成から PR マージまでの流れを 1 本の手順として整理します。

このページで学ぶこと

• ローカルブランチとリモートブランチの違い
• ブランチ名の付け方
• 実装、ステージング、コミット、push の流れ
• PR 作成、レビュー対応、main へのマージ手順
• 迷ったときに確認する基本コマンド

全体像

GitHub を使った基本的な機能開発は、次の順番で進みます。

main を最新にする
  ↓
作業ブランチを作る
  ↓
機能を開発・修正する
  ↓
変更をステージングする
  ↓
コミットする
  ↓
リモートブランチへ push する
  ↓
Pull Request を作成する
  ↓
レビューを受けて修正する
  ↓
承認後に main へマージする

この流れの目的は、未確認の変更を直接 main に入れないことです。作業途中のコードを分けておき、レビューと自動チェックを通してから取り込むことで、変更の意図と品質を確認しやすくなります。

ローカルブランチとリモートブランチの違い

ブランチには、自分の PC 上にあるものと、GitHub 上にあるものがあります。

種類	場所	役割
ローカルブランチ	自分の PC	実装や修正を行う作業場所
リモートブランチ	GitHub 上	PR 作成やチーム共有のための作業場所

たとえば、手元で feature/add-profile-bio というブランチを作っただけでは、GitHub 上にはまだそのブランチは存在しません。git push して初めて、GitHub 上にも同じ名前のリモートブランチが作られます。

git checkout -b feature/add-profile-bio
git push -u origin feature/add-profile-bio

-u は、ローカルブランチとリモートブランチを紐づけるための指定です。2 回目以降は git push だけで同じリモートブランチへ送れるようになります。

Step 1: main を最新にする

作業を始める前に、まず main ブランチを最新にします。古い状態からブランチを作ると、あとでコンフリクトが起きやすくなります。

git checkout main
git pull origin main

この時点で、手元の main は GitHub 上の main と同じ状態になります。

git pull は、リモートの変更を取得して手元のブランチに反映するコマンドです。チーム開発では、他の人が先に変更をマージしている場合があるため、作業開始前の確認として習慣にしておくと安全です。

Step 2: 作業ブランチを作る

次に、今回の機能開発用のブランチを作ります。

git checkout -b feature/add-profile-bio

git checkout -b は、「新しいブランチを作成して、そのブランチに切り替える」コマンドです。

ブランチ名の付け方

ブランチ名は、後から見ても作業内容が分かる名前にします。

feature/add-profile-bio
fix/profile-bio-validation
docs/update-github-flow-guide
refactor/profile-form

よく使う接頭辞は次の通りです。

接頭辞	用途	例
feature/	新機能の追加	feature/add-search
fix/	バグ修正	fix/login-error
docs/	ドキュメント変更	docs/update-readme
refactor/	振る舞いを変えない整理	refactor/profile-form
chore/	設定や周辺作業	chore/update-dependencies

Issue 番号がある場合は、次のように含めると追跡しやすくなります。

feature/42-add-profile-bio

ブランチ名は、短く、英小文字とハイフン中心にすると扱いやすくなります。

Step 3: 機能を開発・修正する

作業ブランチに切り替わった状態で、コードを編集します。

今回の例では、プロフィール画面に自己紹介欄を追加します。

変更例:
- プロフィールフォームに bio 入力欄を追加する
- 最大文字数のバリデーションを追加する
- 保存後に自己紹介文が表示されるようにする

作業中は、こまめに状態を確認します。

git status

git status では、変更されたファイル、ステージング済みのファイル、まだ Git に追跡されていないファイルを確認できます。

Step 4: ステージングする

コミットする前に、コミットに含める変更を選びます。この操作をステージングと呼びます。

git add src/components/ProfileForm.tsx
git add src/pages/profile.tsx

まとめて追加する場合は次のように書けます。

git add .

初心者のうちは、git add . の前に必ず git status を確認することをおすすめします。意図しないファイルや一時ファイルが含まれていないかを確認するためです。

ステージングは、「次のコミットに入れる変更を選ぶ箱」と捉えると分かりやすくなります。作業フォルダで編集しただけでは、まだコミット対象として確定していません。

Step 5: コミットする

ステージングした変更を、履歴として保存します。

git commit -m "feat(profile): add bio field"

コミットは、単なる保存ではなく「何を、なぜ変更したか」を後から確認するための記録です。メッセージは短くても、変更内容が分かるようにします。

コミットメッセージの例

feat(profile): add bio field
fix(profile): validate bio length
test(profile): add bio form tests
docs(git): update pull request workflow

変更が大きい場合は、1 回のコミットにすべてを詰め込まず、意味のある単位に分けます。

git add src/components/ProfileForm.tsx
git commit -m "feat(profile): add bio input"

git add src/lib/validation.ts
git commit -m "fix(profile): validate bio length"

このように分けると、レビューする側も「どの変更が何のためか」を追いやすくなります。

Step 6: リモートブランチへ push する

ローカルでコミットしただけでは、変更はまだ自分の PC にしかありません。GitHub 上で PR を作るには、作業ブランチをリモートに push します。

git push -u origin feature/add-profile-bio

2 回目以降は、次のコマンドで push できます。

git push

push すると、GitHub 上に feature/add-profile-bio というリモートブランチが作成されます。GitHub のリポジトリ画面に「Compare & pull request」ボタンが表示されることがあります。

Step 7: Pull Request を作成する

Pull Request は、「このブランチの変更を main に取り込んでよいか確認してください」という依頼です。

PR を作るときは、次の情報を明確にします。

項目	書く内容
タイトル	何を変更したか
概要	変更内容の要点
理由	なぜこの変更が必要か
確認方法	どう動作確認したか
関連 Issue	対応する Issue 番号

PR 説明の例です。

## 変更内容
- プロフィール画面に自己紹介欄を追加しました
- 自己紹介文の最大文字数チェックを追加しました

## 変更理由
ユーザーがプロフィールに短い紹介文を表示できるようにするためです。

## 確認方法
- プロフィール画面で自己紹介文を入力できることを確認
- 保存後に入力内容が表示されることを確認
- 文字数上限を超えた場合にエラーが表示されることを確認

## 関連 Issue
Closes #42

Closes #42 と書くと、PR が main にマージされたときに Issue #42 が自動でクローズされます。

Step 8: PR レビューを受ける

PR を作成したら、レビュアーに確認してもらいます。レビューでは、主に次の点が見られます。

- 要件を満たしているか
- 既存機能に影響していないか
- コードが読みやすいか
- テストや動作確認が十分か
- セキュリティや権限の問題がないか

GitHub の PR には、主に次のタブがあります。

タブ	見る内容
Conversation	PR の説明、コメント、レビュー結果
Commits	ブランチに含まれるコミット
Checks	自動テストや lint の結果
Files changed	変更差分

自分でレビューする場合も、まず Files changed を見ます。差分を読むと、不要な変更、デバッグ用のログ、消し忘れたコメントに気づきやすくなります。

Step 9: レビューコメントに対応する

レビュアーから修正コメントが来た場合は、同じローカルブランチで修正します。

# feature/add-profile-bio にいることを確認
git branch

# ファイルを修正したあと
git status
git add src/components/ProfileForm.tsx
git commit -m "fix(profile): handle empty bio"
git push

同じブランチに push すると、既存の PR が自動で更新されます。新しい PR を作り直す必要はありません。

修正後は、コメントに返信したり、対応済みの会話を Resolve したりして、レビュアーが再確認しやすい状態にします。

Step 10: PR を main にマージする

レビューで承認され、必要なチェックが通ったら、PR を main にマージします。

GitHub では、代表的に次のマージ方法があります。

方法	特徴
Merge commit	作業ブランチのコミットを残し、マージコミットを作る
Squash and merge	作業ブランチのコミットを 1 つにまとめて取り込む
Rebase and merge	履歴を直線的に並べて取り込む

初心者チームでは、まず Squash and merge が扱いやすいことが多いです。作業中の細かいコミットが main に多く残らず、1 つの機能が 1 つの履歴として見えやすくなるためです。

マージ後は、GitHub 上の作業ブランチを削除します。

Delete branch

ローカルにも不要なブランチが残っている場合は、main を最新にしてから削除します。

git checkout main
git pull origin main
git branch -d feature/add-profile-bio

これで、機能開発の一連の流れは完了です。

よく使うコマンド一覧

目的	コマンド
main に切り替える	git checkout main
main を最新にする	git pull origin main
ブランチを作る	git checkout -b feature/add-profile-bio
状態を確認する	git status
変更をステージングする	git add <file>
コミットする	git commit -m "feat: add profile bio"
リモートに push する	git push -u origin feature/add-profile-bio
2 回目以降 push する	git push
ローカルブランチ一覧を見る	git branch
リモートブランチも含めて見る	git branch -a
マージ済みブランチを削除する	git branch -d feature/add-profile-bio

迷ったときの確認ポイント

GitHub の開発フローで迷ったときは、次の 5 点を確認すると状況を整理しやすくなります。

1. 今どのブランチにいるか
2. 変更したファイルは何か
3. その変更はステージングされているか
4. コミットは作成済みか
5. そのコミットは GitHub に push 済みか

確認に使う基本コマンドは git status と git branch です。困ったときほど、この 2 つを先に見ると原因を切り分けやすくなります。

まとめ

GitHub を使った機能開発は、main を最新にし、作業ブランチを作り、実装し、ステージング、コミット、push、PR、レビュー、マージの順で進めます。

重要なのは、コマンドを丸暗記することではなく、今の変更がローカルにあるのか、リモートにあるのか、PR としてレビュー可能な状態なのかを理解することです。

最初は小さな変更で構いません。1 つの機能をこの流れで最後まで進めると、Git と GitHub の言葉が実際の作業と結びついて理解しやすくなります。

このページの外部仕様・背景情報は、参考文献を参照してください。[1][2]

参考文献

1. Git, Reference
2. GitHub, GitHub Docs