【個人開発向け】もうmainブランチに直接コミットしない！PjMが実践する、たった一人のためのGitブランチ戦略
こんばんは！IT業界で働くアライグマです！
個人開発のプロジェクト、順調に進んでいますか？ 週末の夜、集中してコーディングを進め、キリの良いところでターミナルにこう打ち込む…
git add .
git commit -m "fix"
git push origin main…心当たりのある方、多いのではないでしょうか。
「一人で開発しているんだから、ブランチなんて面倒なだけじゃない？」 その気持ち、痛いほど分かります。私も昔は、mainブランチ一本で、全ての開発を行っていました。しかし、その結果、後からコードを見返すのが困難になったり、新しい機能を試すのが怖くなったりと、多くの「見えない負債」を抱え込むことになったのです。
今日は、そんな過去の私と同じ過ちを、皆さんには繰り返してほしくない、という想いを込めて、たった一人で開発しているからこそ実践すべき、シンプルで強力なGitのワークフローをご紹介します。この記事を読み終える頃には、あなたの個人開発は、チーム開発のようにクリーンで、安全なものへと生まれ変わっているはずです。
なぜ、一人でも「ブランチ」を切るべきなのか？
「一人で開発しているんだから、ブランチなんて面倒なだけじゃない？」 私も、かつてはそう考えていました。しかし、数々の失敗を経て、今では断言できます。個人開発であっても、ブランチを切るという一手間は、将来の自分を救う、最も費用対効果の高い「保険」なのです。その理由は、大きく4つあります。
安全な実験場：いつでも帰れる「母艦」を持つ安心感
mainブランチ（あるいはmaster）を、常にリリース可能な状態に保たれた「母艦」だと考えてみてください。そして、新しい機能の開発は、そこから発進する「小型の探索機（フィーチャーブランチ）」で行うのです。
探索機での作業中、たとえエンジンが爆発しようが、道に迷って遭難しようが、母艦であるmainブランチには何の影響もありません。最悪の場合、その探索機（ブランチ）を丸ごと捨てて、また新しい探索機で母艦から出発すれば良いだけです。
この「いつでも帰れる場所がある」という心理的な安全性は、新しい技術への挑戦や、大胆なリファクタリングを試みる際の、精神的なブレーキを外してくれます。git resetやrevertで過去のコミットを探し回る悪夢から、あなたは完全に解放されるのです。
タスクの明確化：「今、何をすべきか」に集中できる環境
これは、以前ご紹介した「カンバンボードによるタスク管理術」と密接に関連します。 「カンバンボードのカード1枚が、Gitのブランチ1本に対応する」というルールを設けるのです。
例えば、「ユーザー登録機能の実装」というカードを「作業中」に移動させたら、すかさずfeature/implement-registrationというブランチを作成する。そして、その機能が完成し、カードを「完了」に移動させるまで、あなたはそのブランチの中だけで作業します。
このルールにより、あなたは「今、この機能開発だけに集中すれば良い」という、極めてクリアな状態に入ることができます。複数のタスクが頭の中で混線したり、「あれもこれも」と手を出す誘惑から、物理的に自分を守ることができるのです。
美しいコミット履歴：未来の自分が感謝する「読むための歴史」
作業ブランチの中では、あなたのコミット履歴は乱雑で構いません。「wip（Work In Progress）」「fix」「とりあえずコミット」…。それでいいのです。それは、あなたの試行錯誤のリアルな記録です。
重要なのは、その作業ブランチをmainブランチに統合する時です。GitHubのプルリクエストには、「Squash and merge」という機能があります。これは、作業ブランチで行った10回、20回の細かなコミットを、たった一つの一貫性のあるコミットにまとめてから、mainブランチに取り込む機能です。
これにより、mainブランチのコミット履歴は、「ユーザー登録機能を追加」「プロフィール編集機能を実装」といった、非常にクリーンで、意味のある歴史だけが刻まれていきます。git logを叩いた時、そこに表示されるのが、混沌とした作業メモではなく、プロダクトの進化の物語であること。これは、半年後のあなたがバグの原因を調査する際に、何よりの助けとなります。
プロとしての「型」を身につける：個人開発は最高の稽古場
あなたが書くコードは、あなたの作品です。そして、そのバージョン管理の歴史もまた、あなたの仕事の質を示す、重要な作品の一部です。個人開発は、誰にも迷惑をかけずに、プロフェッショナルな開発の「型」を学ぶことができる、最高の稽古場なのです。
将来、あなたが誰かとチームを組むことになった時、あるいはあなたのサービスが成功し、新しい仲間を迎えることになった時。この美しいGitの歴史とワークフローは、あなたの技術的な信頼性を雄弁に物語ってくれるでしょう。
私が実践する「セルフ・プルリクエスト」ワークフロー
では、具体的にどのような手順で進めるのか。GitHub Flowをベースにした、個人開発に最適な、シンプルで実践的なワークフローをご紹介します。
Step1: mainブランチは常に神聖な場所
mainブランチは、常にリリース可能な、安定したコードだけが存在する場所と定義します。ここに、直接コミットすることは絶対にありません。
Step2: 作業は必ずブランチで
新しい機能開発やバグ修正に着手する際は、必ずmainブランチから、目的が明確にわかる名前のブランチを作成します。
# mainブランチを最新の状態にする
git checkout main
git pull origin main
# 新しい機能開発用のブランチを作成して、移動する
git checkout -b feature/add-ranking-featureブランチ名は、feature/機能名
fix/バグ名 のように、接頭辞をつけるルールにすると、一目でブランチの目的がわかって便利です。
Step3: 自由にコミット＆プッシュ
作業ブランチの中では、あなたの自由です。一日の中で、小さな単位で何度もコミットし、GitHubにプッシュしましょう。こまめにプッシュしておくことで、もしあなたのPCに何かあっても、リモートリポジトリがバックアップとして機能します。
Step4: 自分自身に「プルリクエスト」を出す
機能が一通り完成したら、GitHub上で「プルリクエスト（PR）」を作成します。これは、feature/add-ranking-featureブランチからmainブランチへのマージを依頼する、という意味を持ちます。たとえレビュアーが自分一人しかいなくても、この形式的なプロセスを踏むことが非常に重要です。
PRの概要欄には、「なぜこの変更を行ったのか」「どのタスク（Trelloのカードなど）に対応しているのか」「どうやってテストしたか」などを、未来の自分が分かるように書き残しておきます。
Step5: 「セルフ・コードレビュー」を行う
プルリクエストを作成したら、GitHubの「Files changed」タブを開きます。ここが、客観的に自分のコードを見直す、最高の舞台です。 先日お話しした「仕様との整合性」「命名の分かりやすさ」「コメントの質」という3つの視点で、他人になったつもりで、自分自身のコードを厳しくレビューします。タイポや、不要なデバッグコードの消し忘れなど、驚くほど多くの「セルフツッコミ」が見つかるはずです。
Step6: mainへのマージと、ブランチの掃除
セルフレビューが完了し、修正も終えたら、いよいよmainブランチに統合します。GitHub上で「Squash and merge」ボタンをクリックし、美しいコミットメッセージを一つだけ残して、mainに取り込みましょう。 マージが完了したら、不要になった作業ブランチは、ローカルとリモートの両方から削除して、リポジトリを常にきれいな状態に保ちます。
【応用編】バグ修正はどうする？
本番環境で緊急のバグが見つかった場合はどうでしょうか。その際は、hotfixブランチを使います。 mainブランチからhotfix/critical-payment-bugのような名前でブランチを切り、最小限の修正だけを行って、すぐにmainにマージしてデプロイします。そして重要なのは、そのhotfixブランチの変更を、現在進行中のfeatureブランチにも忘れずに取り込むことです。これにより、次の機能リリースの際に、バグ修正が漏れてしまうのを防ぎます。
【PjM視点】なぜ、この一手間がプロジェクトを救うのか
この一連のワークフローは、単なる自己満足の作法ではありません。PjMの視点から見ると、これは極めて合理的なリスク管理と、ドキュメンテーションの自動化なのです。
- リスク管理: フィーチャーブランチは、リスクを完全に隔離する「コンテナ」です。新しい機能がプロジェクト全体を破壊するリスクをゼロにし、いつでも安定版に戻れるという安心感は、開発の速度と品質を両立させる上で不可欠です。
- トレーサビリティ（追跡可能性）: GitHubのプルリクエストの一覧は、それ自体が「いつ、誰が、なぜ、どんな機能を追加したのか」を完璧に記録した、最高の開発ドキュメントになります。PjMは、この一覧を見るだけで、プロジェクトの進捗と歴史を、誰にも質問することなく正確に把握できます。
- 未来への投資: もし、あなたのサービスが成功し、二人目の開発者がチームに加わることになったら？このワークフローが既に存在すれば、あなたは口頭で説明することなく、新しい仲間はプルリクエストの歴史を読むだけで、プロジェクトの全体像をキャッチアップできます。これは、チームの拡大（スケール）を見据えた、最高の投資なのです。
まとめ
バージョン管理を丁寧に行うことは、過去の自分への敬意であり、未来の自分への最高の贈り物です。そして、それはあなたが「プロのソフトウェアエンジニア」であることの、何よりの証明となります。
mainブランチを、常に磨き上げられた製品が置かれる「ショーケース」のように扱い、日々の試行錯誤は、決して表には見せない「作業場のブランチ」で行う。
このシンプルでプロフェッショナルなワークフローを導入し、あなたの個人開発プロジェクトを、単なる「コードの置き場」から、美しい歴史を持つ「誇れるプロダクト」へと育てていってほしいと、心から願っています。