Github Flowの概要
Github FlowはGitのブランチ管理をルール化したシンプルなワークフローで、短いスパンでデプロイをするようなサイトに最適です。既発のGit Flowと違ってインストールの必要もなく、ルールも簡単なため導入コストが低く抑えられます。
Github Flowは必須ブランチがmain以外になく、そのほとんどがmainから作業ブランチを作成、作業終了後に作業ブランチをmainにマージといったシンプルな流れになります。 確認用ブランチが存在しないためシンプルなブランチ管理になっており、デプロイや修正が素早く手軽に行うことができます。
※もともとはmasterブランチが使われていましたが、ポリティカル・コレクトネス的な観点から現在はmainブランチがデフォルトです。
作業用ブランチを作成する際は、短いスパンでデプロイすることを目指し、最小限の作業範囲で作成します。
作業範囲を狭めることにより、大きなバグの発生を抑えられるというメリットもあります。
Github Flowのルールは以下の通りです。
- mainブランチは、常時デプロイ可能な状態を保つ
- 全てのブランチはmainブランチから作成する
- 作業内容が分かるようなブランチ名をつける
- 作業中のブランチは定期的にプッシュする
- Githubのプルリクエストを利用してレビューを行なってから、mainブランチにマージする
- mainブランチにマージしたらデプロイする
- デプロイ後は速やかに作業していたブランチを削除する
シンプルなフローですが、Githubでも採用されているように、数十人規模のチームでも機能している実績があります。
Github Flowのルール
全てのブランチはmainブランチから作成する
mainブランチは常にデプロイ可能な状態が保障されているので、安心してそこから新しいブランチを作成することができます。
mainブランチは、常時デプロイ可能な状態を保つ
mainブランチにマージしたらデプロイする
この2つのルールにより、mainブランチ=本番環境ということが保証されます。また、mainブランチには開発途中のものや、既知のバグがない状態と言えるので、安心してmainから新しいブランチを作成できます。
この2つのルールは、Gitの作業フローの中でも非常に重要といえます。
作業内容が分かるブランチ名をつける
ブランチ名から作業内容が推測できると、複数のブランチを管理する際に便利です。ブランチの種類を改修・機能追加とバグフィックスの2つに分けて、下記のような命名法を決めても良いでしょう。
- 機能追加：feature-機能を表す名称
例） feature-user-notice - バグフィックス：fix-修正を表す名称
例） fix-login-validation - 変更：mod-変更内容を表す名称
例）mod-color-change
また、このルールの利点として、fetchすると他の開発者が作業しているトピックを知ることができる、という点も挙げられます。
作業中のブランチは定期的にプッシュする
作業中のブランチを定期的にpushすると、その時点の最新の作業がリモートにバックアップされます。この利点以外にも、他開発者が git getch すれば自分以外の課題がどのように進んでいるのかを確認できます。
プルリクエストでレビューを行なってから、mainブランチにマージする
Githubにはプルリクエストというコードレビューの仕組みがあります。他の開発者にプルリクエストを送り、確認や助言をしてもらいます。これで問題なければ、mainブランチにマージします。
デプロイ後は速やかに作業していたブランチを削除する
作業が終ったブランチがいつまでも残らないように、ローカル、リモートでデプロイしたブランチを削除します。古いブランチが残っていると、ブランチの管理が難しくなり、ミスのもとにもなります。
以上がGithub Flowを使った運用ルールになります。守るべきルールはこれだけなので、学習コストもそれほどかからないと思います。基本的にはすべて守るのがベストですが、HTMLやCSSのみの小規模なプロジェクトであれば、プルリクエストによるコードレビューは省略可能です。レビューしたほうがベストですが、レビューを省略した場合のリスクは比較的抑えやすいので、コストを考えると省略を検討しても良いかと思います。