Day 3・ブランチと実務フロー — チームで壊さず進める
ブランチ＝作業の「分身/パラレルワールド」
main を壊さずに新しい試みができるブランチを、コピー原稿のたとえで理解し、git switch -c で作れるようになる。
ブランチは「もう一つの自分の作業場」
ブランチは、今の状態をそのまま引き継いだ「作業の分身」です。SFでいうパラレルワールドをイメージしてください。元の世界(main)はそのまま置いておいて、別の世界で「もし新機能を足したら?」を自由に試せます。うまくいけば合流(merge)させ、ダメなら世界ごと捨てればいい。だから安心して実験できます。
もっと身近なたとえなら、清書した本番の原稿(main)を汚さずに、コピーを取ってそのコピーの上で下書きや修正を試すのと同じです。コピーにどれだけ赤ペンを入れても、本番の原稿は無傷。気に入ったらコピーの内容を本番に反映すればいいのです。
# 今どこにいるか(ブランチ一覧、* が現在地)
git branch
# feature/login という新しいブランチを作って、そこへ移動する
git switch -c feature/login
# もとの main に戻りたくなったら
git switch main-c は create(作る)の c です。git switch -c feature/login と打つと、feature/login という名前の分身を作り、その世界へ自分が移動します。ここでコミットしても main は一切変わりません。安心して壊せる場所ができた、ということです。
- main = みんなが信頼している「正」の世界。ここは丁寧に扱う。
- feature/〇〇 = 新機能を試す分身。名前で「何をやっているか」が伝わる。
- fix/〇〇 = バグ修正用の分身。目的別に名前を付けるのが現場の習慣。
なぜわざわざブランチを分けるのか
main を直接いじると、途中の壊れた状態が「正」の世界に混ざってしまいます。ブランチを切れば、完成するまで実験を隔離できるので、他の人の作業やリリースを巻き込まずに済みます。「壊しても戻せる安心」を、チーム全体に広げる仕組みがブランチです。
作業前にブランチを切る癖を
「ちょっとだけだから」と main で作業を始めると、あとで分けたくなったとき面倒になります。何かを変え始める前に、まず git switch -c で分身を作る。これを最初の一手にしておくと、事故がぐっと減ります。
AIにはこう聞く
「今 main にいます。ログイン機能を試したいので、feature/login というブランチを作ってそこに移動するGitコマンドを教えて。今どのブランチにいるか確認する方法も教えて」
読んでも腑に落ちない所は、AIに噛み砕いてもらいましょう。
理解度チェック
答えられれば、面接で説明できる状態に一歩近づきます。
git switch -c feature/login を実行すると何が起きる?
「ブランチとは何か」を、プログラミングを知らない人にもわかるようにたとえで説明してください。
記述式です。まず自分の言葉で答えを考えてから、模範解答を開いて自己採点してください。