この記事、実は旅の宿から書いています。旅先でもノートパソコンを開いて手を動かしていると、いつもと違う場所だからか、意外と素直に「なるほど」と腑に落ちる瞬間があります。
今回のテーマは「ブランチ」です。一人で開発していると「ブランチなんて、チーム開発の人が使うものでは？」と思いがちですが、実はそうでもありません。
main に直接プッシュして壊れる問題
前回までの流れだと、main ブランチに向かって直接 git add → git commit → git push を繰り返す形になります。慣れないうちは、これで十分動きます。
ただ、新しい画面を作っている途中で「あ、今日はここまでにしよう」と一旦区切りたいのに、中途半端な状態のコードが main に残ってしまう、ということが起こりがちです。個人開発でも、main はいつでも「今すぐ動く状態」にしておきたいところです。
そこで登場するのが、作業用の場所を分ける「ブランチ」という考え方です。
「本番用（main）」と「作業用（feature/xxx）」を分けるメリット
イメージとしては、main を「完成品を並べる棚」、ブランチを「作業台」だと考えるとわかりやすいです。
- main：常にきれいな状態を保つ、完成した機能だけを置く場所
- feature/xxx：新しい機能を作っている最中の、散らかっていてもいい作業スペース
作業台（ブランチ）でどれだけ試行錯誤しても、棚（main）は汚れません。うまくいかなければ、そのブランチごと諦めて作り直すこともできます。
実際の手順：ブランチ作成 → 変更 → プッシュ
git switch -c feature/add-map-screen
これで feature/add-map-screen という作業用ブランチができ、そこに切り替わります。
あとはいつも通り、変更を加えて記録していきます。
git add .
git commit -m "add map screen UI"
git push -u origin feature/add-map-screen
main には影響を与えず、feature/add-map-screen という別の場所に記録が積み重なっていきます。
GitHub上で「Pull Request（PR）」を作ってみる
作業が一区切りついたら、GitHub上でこのブランチを main に取り込むための「Pull Request（PR）」を作成します。
一人開発だと「レビューしてくれる人もいないのに、PRを作る意味あるの？」と思うかもしれません。私も最初はそう思っていました。ただ実際にやってみると、
- 変更内容が一覧で見えるので、「今回何を変えたか」を自分自身で見直せる
- PRの説明欄に「なぜこの変更をしたか」を書く習慣がつく
- あとから「あの機能、いつ・なぜ追加したんだっけ」を振り返りやすい
という、自分用の記録・振り返りツールとしての価値がありました。マージするタイミングも自分で決められるので、「もう少し寝かせてから取り込もう」という判断もしやすくなります。
やらかしレスキュー策：違うブランチで作業してしまった
main にいるつもりで作業していたら、実は昨日作った別のブランチのままだった——これもよくある事故です。
まず、今どのブランチにいるかは、いつでもこれで確認できます。
git branch
アスタリスク（*）が付いているのが現在のブランチです。もし違うブランチで作業してしまっていても、コミットする前であれば慌てなくて大丈夫です。
git switch main
で本来のブランチに戻り、必要であれば作業を仕切り直せます。すでにコミットしてしまった後の場合は、変更を正しいブランチに持っていく方法もありますが、それはまた別の回で扱えたらと思います。
次回予告
次回は、開発者がいちばんヒヤッとする「APIキーや秘密鍵の管理術」を扱います。うっかりプッシュしてしまった時の緊急対処法も含めて、事故を防ぐための回にする予定です。
旅先の空気を吸いながら書いていると、旅と開発が地続きになっているような不思議な感覚があります。次回もよろしくお願いします。
