個人開発者「個人開発でのGitフローって何が最善なのだろう…masterブランチにdevelopブランチにreleaseブランチにfeatureブランチ…多すぎる気がするけどネットには必要って書いてるし…もっとシンプルにしたい」
こんな疑問に答えます。
本記事の内容
- 個人開発に特化したGitのブランチの切り方の解説
- 必要なのはmasterとfeatureの2つだけ
書いている人の実績
- 個人開発したサービスを10年間運営＆改修
- 個人開発したサービスのPVは10年間で6億PV
- 現在月間PV700万〜800万
- 個人開発したサービスで毎月50万円以上の収益
個人開発でのGitフローはmasterと改修時に切るfeatureブランチだけでOK
複数人で開発する訳では無いので大元のブランチはmasterだけでOKです。
本番リリースする時はmasterブランチからリリースします。
改修をする時はmasterからfeatureブランチを切ります。
リリースをする時はfeatureブランチをmasterにマージして完了です。
developやreleaseブランチは不要です。
なぜなのか？
これはそもそも一人で開発しているので大元のブランチはmaster一本あればよいのです。
個人開発の場合はdevelopブランチもreleaseブランチも結局はmasterと同じ内容になります。
僕はこの方法で開発とリリースを繰り返していますが、未だ困ったことはありません。
改修とリリースをなるべく素早いスパンで繰り返したいのであればこれが最善です。
僕が実際に行っている具体的な方法を以下で解説します。
なお、実際のソースはGithubでホストしています。
個人開発でmasterとfeatureブランチだけで運用する方法
1. masterからfeatureブランチを切る
まずはmasterから機能開発するためのブランチを切ります。
$ git checkout -b feature/grate_hogehoge機能開発ではなくバグフィックスの場合は、feature/ではなくbugfix/としてもよいです。
この辺りは好みなのでお好きに書きましょう。
# バグフィックスの場合
$ git checkout -b bugfix/unko_hogehoge改修が終わったらコミットです。
2．改修が終わったらfeatureブランチへコミット＆リモートにプッシュ
# gitにファイル追加
$ git add <ファイル名>
# コミット
$ git commit -m "#4 最高の改修を圧倒的に生産してやったぜ"
# リモートにプッシュ
$ git push origin feature/grate_hogehogeちなみに個人開発ではプッシュのタイミングにこだわる必要はありません。
僕はある程度まとまった機能開発の単位や、ステージング環境で確認したい時にプッシュしています。
ちなみにGithubではプッシュすることでIssuesに紐付けたコミットコメントが表示されたりするので、僕の場合はモチベーションを高めるためにこまめにプッシュしたりします。
3．featureブランチからステージング環境にリリースしてテスト
ここまで来たらステージング環境にリリース（デプロイ）して動作確認をします。
やはりローカルとステージングで挙動が変わることがあるので、ここでの確認は比較的時間をかけます。
この確認で問題が無ければプルリクエストを出してfeatureブランチをmasterにマージします。
4. プルリクエストを出してfeatureブランチをmasterへマージ
Githubであればプッシュした段階でプルリクエストが出せるようになるので自分でプルリクエストを作成します。
コンフリクトが起こらなければそのままマージしてやりましょう。
たったこれだけです。
楽勝ですね。
もしかすると、普段業務でややこしいGitフローに頭を悩ませている人もいるのではないでしょうか。
しかし個人開発ではたったこれだけのフローで何の問題もありません。
個人開発でGitのフローに悩んでいる方は是非試してみてください。
マジでオススメします。
masterへの直コミットはダメ絶対
いくら個人開発が自由で気軽だといえどもmasterへの直コミットだけはやめましょう。
時間が経った時に改修した内容を機能単位で追えるのがブランチの強みです。それができないと本当に困ったことになることがあります。
いくらコミットコメントを残していても、ブランチはきっちり切りましょう。
ちなみに僕のサービスのブランチはこんな感じです。
青の線がmaster、そこから生えているのが各featureブランチです。
だいたいmasterと一つのfeatureブランチしか無いので非常にシンプルです。
仮にfeatureブランチが同時に2つ以上存在する場合も、常にmasterから切りますのでややこしくなることはありません。
まとめ
- 個人開発に特化したGitのブランチの切り方の解説
- 必要なのはmasterとfeatureの2つだけ
個人開発でGitフローをややしくすることは百害あって一利なしです。
最初はちょっと慣れないかも知れませんがとりあえず手を動かしてみましょう。
最初から自分に最適の方法が用意されている人なんていません。
Gitログが増えて来るとモチベーションの向上にも繋がります。
これを読んだだけでは何も生まれません。
「とりあえず1日1コミットと1プッシュ」
これを目標に頑張ってみましょう。
それではよき個人開発ライフを！
