1人で開発してると、masterブランチに全部コミットしがちでカオスになったり、ある機能の実装中に、全く関係ない部分のリファクタリングを始めちゃったり、別の作業をうっかり始めちゃったりしがちでしたが、複数人での開発を想定してGithub flowを取り入れてみると、結構メリットが多かった気がするので、個人開発のためのgithub flowをテーマに記事を書いて、まとめてみました。
自分用なのであまり人に読ませる気がないですがすみません。
個人開発でGithub flowを取り入れるメリット
- 実装する機能毎にブランチを切ることで、これからやる作業が頭の中で明確になる→だらだらと無関係な箇所のリファクタリングをしなくなり時間が増える
- 複数人での開発に備えることができる
- プルリクを挟むことで、自分で書いたコードを客観的に見つめ直せる
- githubに草が生えまくる
masterブランチは、常時デプロイ可能な状態を保つ
全てのブランチはmasterブランチから作成する
トピックブランチの段階でエラーがあった場合はそのままmargeされリリースされる流れになってしまうので、
プルリクの段階でマージする前にきちんとテストしとけということですね。
また、基本的にmasterブランチでの作業は禁止です。
作業内容が分かるようなブランチ名を
（例）20200214/feature-user-create
（例）20200129/init-react-setup
（例）20200311/hotfix-css-for-ie11
/(スラッシュ)を含めることで階層構造になる。
また、作業月を含めて直感的に作業内容が思い出せるように。
featureやinit、hotfix、releaseで大別しつつ、詳細な機能内容を含める。
数日後見た時にどれがどの作業かを分かるようにしたい。後々プルリクしてissueと紐づける際にも、ちゃんとした命名してると楽。
作業中のブランチは定期的にプッシュする
最新の作業内容をリモート上にバックアップする目的と、他者が進捗を確認できるという利点があるそうですが、
マメにコミットするクセがついていれば良いですが、ついていなければ、定期的にプッシュするということを意識することで、こまめにコミットもしくはプッシュする習慣をつけられるのではと思います。
Githubのプルリクエストを利用してレビューを行なってから、masterブランチにマージする
自作自演で醜いですが、今後の他者との協業を考慮して、自分でプルリクを出します。
もう1人の僕（←)の気持ちに切り替えて客観的にコードを見直してみると、ここ見辛っとか、もっとスマートな書き方あったやんと気付けたりします。githubの同ページ上でマージもそのまま行えるのでそこまで手間ではないです。
マージされたらそのままリリースまで行ってしまうので、レビューの段階できちんとテストする必要があります。
issueがあれば紐づけるのを忘れないようにする。忘れそうであればプルリク時に「close #」を入れとく。
マージされたmasterブランチのコードはすぐにデプロイする
最近ではCI環境が整ってるので絶対にないですが、昔はgit上のソースと本番環境上のソースでどちらが最新なのか分からない状況があったので、もしCI環境が導入されていて自動デプロイ可能な状態でないなら、とにかく最新のmasterブランチと本番環境は常に合わせておくことを意識したいです。
デプロイ後は速やかに作業していたブランチを削除する
自分がにわとり並の脳味噌なので2〜3日したら、どれがMarge済みかどれがプルリク済みかが分からなくなってしまうので、作業済みのブランチはローカルからもリモートからも削除するようにします。
いちいちトピックブランチを作るのがめんどくさい場合
真っ先にdevelopeブランチを作成し、そこで開発。区切りがいいところでmasterブランチにマージする。
