【個人開発向け】もうmainブランチに直接コミットしない！PjMが実践する、たった一人のためのGitブランチ戦略
こんばんは！IT業界で働くアライグマです！
「一人で開発してるだけなのに、いちいちブランチ作るのって面倒じゃない？」
個人開発を進めていると、つい main ブランチに直接コミットしてしまいがちですよね。私も昔はそうでした。しかし、その一手間を惜しんだがために、私が経験したプロジェクトでは、後で「あの機能を追加する前の状態に戻したい…」「どこでバグを埋め込んだんだっけ…」と、コミット履歴を遡るのに多大な時間を溶かしてしまった経験が何度もあります。
本記事では、個人開発だからこそ実践してほしい、たった一人のためのGitブランチ戦略を解説します。このワークフローを導入すれば、安全に新しい機能を試せるだけでなく、未来の自分が感謝するほど美しい開発の歴史を記録できるようになります。
実際に私も、このセルフプルリクエストの習慣を徹底したことで、個人プロジェクトのコード品質が劇的に向上し、半年前に書いたコードですら意図をすぐに思い出せるようになりました。結果的に、開発スピードも上がったのです。
なぜ、一人でも「ブランチ」を切るべきなのか？
「一人で開発しているんだから、ブランチなんて面倒なだけじゃない？」 私も、かつてはそう考えていました。しかし、数々の失敗を経て、今では断言できます。個人開発であっても、ブランチを切るという一手間は、将来の自分を救う、最も費用対効果の高い「保険」なのです。その理由は、大きく4つあります。
安全な実験場：いつでも帰れる「母艦」を持つ安心感
プロジェクトマネージャーとして多くのチーム開発を見てきましたが、成功しているプロジェクトは例外なく main ブランチを神聖なものとして扱っています。これは個人開発でも全く同じです。main ブランチを、常にリリース可能な状態に保たれた「母艦」だと考えてみてください。そして、新しい機能の開発は、そこから発進する「小型の探索機（フィーチャーブランチ）」で行うのです。
探索機での作業中、たとえエンジンが爆発しようが、道に迷って遭難しようが、母艦である main ブランチには何の影響もありません。最悪の場合、その探索機（ブランチ）を丸ごと捨てて、また新しい探索機で母艦から出発すれば良いだけです。この「いつでも帰れる場所がある」という心理的な安全性は、新しい技術への挑戦や、大胆なリファクタリングを試みる際の、精神的なブレーキを外してくれます。 git reset や revert で過去のコミットを探し回る悪夢から、あなたは完全に解放されるのです。
この感覚は、高機能な開発ツールを使うことでさらに強化されます。例えば、Clean Code アジャイルソフトウェア達人の技やリファクタリング(第2版)のような本で紹介されている原則をサポートするツールは、ブランチ操作の心理的ハードルを大きく下げてくれます。
意思決定基準： 新しい機能やリファクタリングに着手する際は、必ずブランチを切り、 main を汚染しない。
タスクの明確化：「今、何をすべきか」に集中できる環境
個人開発では、自分自身がタスク管理者です。だからこそ、物理的な仕組みで集中を維持することが重要になります。私のおすすめは「カンバンボードのカード1枚が、Gitのブランチ1本に対応する」というルールです。
例えば、もっと思い通りに使うための Notion データベース・API活用入門やTrelloで「ユーザー登録機能の実装」というカードを「作業中」に移動させたら、すかさず feature/implement-registration というブランチを作成する。そして、その機能が完成し、カードを「完了」に移動させるまで、あなたはそのブランチの中だけで作業します。このルールにより、あなたは「今、この機能開発だけに集中すれば良い」という、極めてクリアな状態に入ることができます。複数のタスクが頭の中で混線したり、「あれもこれも」と手を出す誘惑から、物理的に自分を守ることができるのです。
意思決定基準： 1つのブランチでは1つの関心事のみを扱うようにし、タスクとブランチを1対1で対応させる。
美しいコミット履歴：未来の自分が感謝する「読むための歴史」
作業ブランチの中では、あなたのコミット履歴は乱雑で構いません。「wip（Work In Progress）」「fix」「とりあえずコミット」…。それでいいのです。それは、あなたの試行錯誤のリアルな記録です。
重要なのは、その作業ブランチを main ブランチに統合する時です。GitHubのプルリクエストには、「Squash and merge」という機能があります。これは、作業ブランチで行った10回、20回の細かなコミットを、たった一つの一貫性のあるコミットにまとめてから、main ブランチに取り込む機能です。これにより、main ブランチのコミット履歴は、「ユーザー登録機能を追加」「プロフィール編集機能を実装」といった、非常にクリーンで、意味のある歴史だけが刻まれていきます。git log を叩いた時、そこに表示されるのが、混沌とした作業メモではなく、プロダクトの進化の物語であること。これは、半年後のあなたがバグの原因を調査する際に、何よりの助けとなります。このあたりの作法は、良質な技術書を読むことで体系的に学べます。達人プログラマーは、まさにそうした思考の「型」を教えてくれる一冊です。
意思決定基準：
mainブランチへのマージ時は Squash and merge を使い、コミット履歴を意味のある単位にまとめる。
プロとしての「型」を身につける：個人開発は最高の稽古場
あなたが書くコードは、あなたの作品です。そして、そのバージョン管理の歴史もまた、あなたの仕事の質を示す、重要な作品の一部です。個人開発は、誰にも迷惑をかけずに、プロフェッショナルな開発の「型」を学ぶことができる、最高の稽古場なのです。
将来、あなたが誰かとチームを組むことになった時、あるいはあなたのサービスが成功し、新しい仲間を迎えることになった時。この美しいGitの歴史とワークフローは、あなたの技術的な信頼性を雄弁に物語ってくれるでしょう。こうした基本を疎かにしない姿勢は、コードレビュー文化の根付いたチームでも高く評価されます。
意思決定基準： 個人開発を、チーム開発の予行演習と捉え、常にプロとしての作法を意識する。
私が実践する「セルフ・プルリクエスト」ワークフロー
では、具体的にどのような手順で進めるのか。GitHub Flowをベースにした、個人開発に最適な、シンプルで実践的なワークフローをご紹介します。このフローを身につければ、あなたの開発プロセスは劇的に整理されます。
Step1: mainブランチは常に神聖な場所
まず、main ブランチは、常にリリース可能な、安定したコードだけが存在する場所と定義します。ここに、直接コミットすることは絶対にありません。これはチーム開発における鉄則ですが、個人開発でも同様に重要です。このルールを守るだけで、予期せぬバグが本番環境に紛れ込むリスクを大幅に低減できます。
意思決定基準：
main ブランチには決して直接コミットしない。
Step2: 作業は必ずブランチで
新しい機能開発やバグ修正に着手する際は、必ず main ブランチから、目的が明確にわかる名前のブランチを作成します。ブランチ名は、feature/機能名
fix/バグ名 のように、接頭辞をつけるルールにすると、一目でブランチの目的がわかって便利です。例えば、feature/add-ranking-feature のような具体的な名前が良いでしょう。
意思決定基準： ブランチ名は feature/ や fix/ などの接頭辞をつけ、目的を明確にする。
Step3: 自由にコミット＆プッシュ
作業ブランチの中では、あなたの自由です。一日の中で、小さな単位で何度もコミットし、GitHubにプッシュしましょう。こまめにプッシュしておくことで、もしあなたのPCに何かあっても、リモートリポジトリがバックアップとして機能します。ローカルでの作業が長くなると、PCの故障などで作業内容が失われるリスクがあります。私自身、過去にApple 2024 Mac mini M4 Pro 12コアCPU 16コアGPU 24GBユニファイドメモリ 512GB SSDのトラブルで数時間分の作業を失いかけたことがありますが、こまめなプッシュのおかげで事なきを得ました。
意思決定基準： 作業の区切りが良いタイミングで、こまめにコミット＆プッシュする。
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 ブランチにも忘れずに取り込むことです。これにより、次の機能リリースの際に、バグ修正が漏れてしまうのを防ぎます。こうした緊急時の対応こそ、普段のワークフローが確立されているかどうかが問われます。日頃からデバッグのテクニックを磨いておくことも、迅速なバグ修正に繋がります。
意思決定基準： 緊急のバグ修正は hotfix ブランチで行い、修正内容は開発ブランチにも必ず反映させる。
【PjM視点】なぜ、この一手間がプロジェクトを救うのか
この一連のワークフローは、単なる自己満足の作法ではありません。PjMの視点から見ると、これは極めて合理的なリスク管理と、ドキュメンテーションの自動化なのです。
- リスク管理: フィーチャーブランチは、リスクを完全に隔離する「コンテナ」です。新しい機能がプロジェクト全体を破壊するリスクをゼロにし、いつでも安定版に戻れるという安心感は、開発の速度と品質を両立させる上で不可欠です。
- トレーサビリティ（追跡可能性）: GitHubのプルリクエストの一覧は、それ自体が「いつ、誰が、なぜ、どんな機能を追加したのか」を完璧に記録した、最高の開発ドキュメントになります。PjMは、この一覧を見るだけで、プロジェクトの進捗と歴史を、誰にも質問することなく正確に把握できます。
- 未来への投資: もし、あなたのサービスが成功し、二人目の開発者がチームに加わることになったら？このワークフローが既に存在すれば、あなたは口頭で説明することなく、新しい仲間はプルリクエストの歴史を読むだけで、プロジェクトの全体像をキャッチアップできます。これは、チームの拡大（スケール）を見据えた、最高の投資なのです。効率的な開発体制の構築は、リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだすにおいても重要な要素となります。
意思決定基準： 手間を惜しまずワークフローを遵守することが、将来の技術的負債を抑制し、プロジェクトの健全性を保つ。
まとめ
本記事では、個人開発者こそ実践すべきGitのブランチ戦略と、具体的なセルフプルリクエストのワークフローについて解説しました。main ブランチを常にクリーンに保ち、すべての作業をブランチで行う。この習慣は、あなたの開発プロセスに規律と安全性をもたらします。
バージョン管理を丁寧に行うことは、過去の自分への敬意であり、未来の自分への最高の贈り物です。そして、それはあなたが「プロのソフトウェアエンジニア」であることの、何よりの証明となります。
main ブランチを、常に磨き上げられた製品が置かれる「ショーケース」のように扱い、日々の試行錯誤は、決して表には見せない「作業場のブランチ」で行う。このシンプルでプロフェッショナルなワークフローを導入し、あなたの個人開発プロジェクトを、単なる「コードの置き場」から、美しい歴史を持つ「誇れるプロダクト」へと育てていってほしいと、心から願っています。快適な開発環境を整えるために、SANODESK 昇降デスク QS1 パソコンデスクを構築するのも良い投資です。
この記事が、あなたの個人開発の一助となれば幸いです。