実務フロー — Issueからmergeまでの一本道

現場は「一人で決めて終わり」ではない

個人開発なら、自分のブランチで作って main に合流させれば完了です。ですが現場(チーム)では、他の人が安心できるよう「この変更、入れてもいい?」と一度確認を挟みます。そのための一連の流れが、実務フローです。レストランで例えるなら、料理をいきなり客に出すのではなく、いったんチェック台に置いて先輩が味見してからホールに出す、という段取りに近いです。

1. Issue(やることチケット): 「ログイン機能を作る」など、やるべき作業を書き出した札。
2. ブランチ作成: その作業用の分身を git switch -c で用意する。
3. 変更してPush: コードを直してコミットし、リモート(GitHub)へ送る。
4. Pull Request(PR): 「この変更を main に入れてください」というレビュー依頼を出す。
5. レビュー: 他の人が中身を読み、コメントや指摘をする。
6. merge: OKが出たら main に合流。作業完了。

Pull Request(プルリク、PR)は、この流れの主役です。「私のブランチの変更を、あなたたちの main に取り込んで(pull して)ほしい」というお願いの手紙だと思ってください。手紙には「何を・なぜ変えたか」を書いておくと、レビューする人が読みやすくなります。

# 1. 作業ブランチを作る
git switch -c feature/login

# 2. 変更してコミット
git add .
git commit -m "add login form"

# 3. リモートへ送る(この後 GitHub 上で PR を作る)
git push -u origin feature/login