いままで開発を進めてくるにあたり、なんとなくgit-flowを使っていたので、まとめてみる。

git-flow

デスクトップ／モバイルアプリケーションのように「リリース」を必要とするソフトウェアの開発に適している。

> 引用：　https://nvie.com/posts/a-successful-git-branching-model/

ブランチの種類と用途

ブランチはメインブランチとサポートブランチに分類される。

メインブランチ（常に存在するブランチ）: main, develop
サポートブランチ（タスクに応じて作成する）: feature, hotfix, release

mainブランチ

リリース済みのコードを管理するためのブランチ

developブランチ

開発中のコードを管理するためのブランチ

featureブランチ

developブランチから派生させる。
主にこのブランチで開発を進めていき、マージするときにはdevelopブランチへマージする。
マージしたあとは基本的には削除していく。
命名はfeature/タスクの内容またはfeature-タスクの内容とする。

releaseブランチ

developブランチから派生させる。
リリース前の準備を行うブランチ。
マージ先は、developブランチとmasterブランチ
命名はrelease-タスク内容

hotfixブランチ

mainブランチから派生させる。
緊急の修正対応などを行う。
マージ先はdevelopブランチとmasterブランチ
命名はhotfix-タスク内容

個人開発では、releaseやhotfixブランチを使うことがなかった。

Github-flow

git-flowよりもシンプル。1日に数回、デプロイを行うようなWebアプリケーションの開発に向いているらしい。
masterブランチとfeatureブランチのみで開発を進めていく。

Github-flowの6つのルール

masterブランチは常にデプロイ可能な状態
作業用ブランチはmasterブランチから派生させる
作業用ブランチは定期的にプッシュする
プルリクエストを活用する
プルリクエストが承諾されたら、masterにマージする
masterへのマージが完了したら、すぐにデプロイを行う

まとめ

githubチームはGithub-flowを使っているようで、そのシンプルな設計が確かに良いと感じた。良さを活かすためにはルールの3. 作業用ブランチは定期的にプッシュすると4. プルリクエストを活用するが結構大切だと思いながら参考資料を読んでいた。
開発する速度や種類によって使い分けが必要だと思うが、個人開発などではGithub-flowで開発していれば大丈夫だと思う。

参考