個人開発でも Git flow を崩さない理由

この記事は、やさしいアドベントカレンダー 20 日目の記事です

きっかけ

個人開発だからと言って「どうせ一人だし」と main ブランチに直接コミットしていた時期がありました
しかし、ある日突然「あのときの変更、いつどこでやったっけ？」と迷子になり、
それ以降は個人開発でも Git flow をきちんと守ることにしました

なぜ個人開発でも Git flow を守るのか

後から見返したときに理解しやすい

ブランチ名に feature/add-user-auth や fix/login-validation のような名前をつけることで、
数ヶ月後に見返したときでも「このときはこの機能を追加していたんだな」と一目で分かります
main に直接コミットすると、コミットログを遡っても前後関係が掴みにくくなりがちです

作業の切り替えがしやすい

新機能を作っている途中で急にバグ報告が来たとき、
ブランチを切り替えるだけでクリーンな状態から hotfix ブランチを作れます
main で作業していると、中途半端な変更を stash したり commit したりする手間が増えます

プルリクエストで自己レビューできる

GitHub で PR を作ると、自分のコードを客観的に眺められます
「あ、ここデバッグ用のコード残ってる」「この変数名微妙だな」といった気づきが生まれやすいです
main に直接 push すると、こうした振り返りの機会を逃してしまいます

CI/CD との相性が良い

PR ベースでテストやリントを走らせる設定にしておけば、
main にマージする前に自動で品質チェックができます
個人開発でも CI を回すことで、うっかりミスを事前に防げます

将来的にチーム開発に移行しやすい

個人プロジェクトが成長してコントリビューターが増えたとき、
最初から Git flow が整っていれば移行コストがかかりません
「後で整理しよう」と思っても、実際にはなかなか手がつけられないものです

実際の運用方法

私は基本的に以下のような流れで開発しています

1. main から feature/xxx や fix/xxx ブランチを切る
2. ローカルで開発してコミットを積む
3. GitHub に push して PR を作成
4. 自己レビューして問題なければ main にマージ
5. 不要になったブランチは削除

シンプルですが、このフローを守るだけでコードの履歴が格段に追いやすくなりました！

個人開発だからこそ丁寧に

「一人だから適当でいい」という考え方もありますが、
むしろ一人だからこそ、未来の自分が困らないように丁寧に管理する必要があると感じています
Git flow を守ることで、過去の自分が何を考えていたのかを辿りやすくなり、
開発のテンポを崩さずに作業を続けられるようになりました

個人開発でも Git flow を意識してみると、コードの質とメンテナンス性が確実に向上します
まだ試したことがない方は、ぜひ一度取り入れてみてください！