GitFlowとGitHub Flowの違い
| 機能 | GitFlow | GitHub Flow |
|---|---|---|
| ブランチ名 | master/develop/feature/hotfix/relase | masterのみ制定 |
| マージ方法 | マージ | PullRequestでマージ |
| リリース | GitFlowリリースのリリース手順 | masterブランチを常時リリース可能にしておく |
git flowとgithub flowとは？その違いは？ - Qiita
GitFlow
ブランチの命名規則やコミットのタイミングについて規定されたものです。
git flowとgithub flowとは？その違いは？ - Qiita
基本的なブランチのルール
developブランチ
このブランチを元に機能ブランチを作成する、ベースとなるブランチです。
GitHubであればDefault Branchをdevelopにしておきます。
featureブランチ
機能開発を行うブランチです。featureという名前ですがバグ取りもこのブランチで行います。
Git（SourceTree）ではブランチ名をスラッシュで区切ることでグルーピングされるため、feature/... として作成します。
featureブランチの命名規則
featureブランチはスラッシュで区切ることができるため、ここに複数の情報を入れます。
具体的には
feature/201902/yousan/fix-admin-panel
といった形で作成しています。
feature/(yearmonth)/(username)/content
となっています。
その理由について述べます。
年月を入れる
featureの下に年月を入れています。
これはSourceTreeを使った場合のグルーピングやブランチ名でソートした場合、時間順でグルーピング、ソートすることができるからです。
開発が長くなってくるとブランチの数がそれなりに増えてきます。だいたい100個を超えたあたりから探すことが大変になってきます。
そこでこのようにスラッシュで区切ることで見通しを良くします。
GitHubのブランチはGitHub上で削除することができますが、Gitの実際の削除ではなく、GitHub上のソフトデリートです。
そのためGitコマンドなどで確認すると生きているブランチとして見えるため、「ちょっとこのブランチをチェックアウトして確認してほしい」とレビュー依頼を出す際など、探すことが困難になります。
こうしてグルーピングしておけば、少なくとも最新の月で絞り込めるため便利です。
Deleting and restoring branches in a pull request - GitHub Help
（削除について間違っているかもなのでその場合には教えてください）
ユーザ名を入れる
ブランチ名にユーザ名（GitHubやSlackのユーザ名と揃えています）を入れます。
こちらも上記の理由と同じく、見通しを良くするということがあります。
またその他にもブランチの持ち主を特定するために入れています。「このブランチって使われてないけど、消して良いのかな…。誰に聞けば良いんだ…」ということを防ぐことが出来ます。
またプルリクエストと同様に責任者を明らかにする、ということがあります。
「このブランチは俺のブランチだから、テストが通らなければ俺が直す責任がある」ということで、責任の所在をはっきりさせることができます。
新人エンジニアに覚えてもらいたいPullRequestの書き方 - Qiita
releaseブランチ
リリース時に利用します。
リリース用の調整を行ったり、ステージング環境へ反映させたりします。
CIサービスで自動デプロイする際の判定などにも使っています。
masterブランチ
ほぼreleaseブランチと同義ですが、各種バージョンが打たれているブランチです。
GitFlowのリリース機能で自動的にコミットしています。
hotfixについて
チーム内でGitにある程度詳しい人がhotfixブランチを作成する。ブランチ名は hotfix/v1.4.19 など、ホットフィックス適用後の次期バージョン名とします。
修正がある人は、ホットフィックスブランチからブランチを作成し、修正を行う。
例: hotfix/202004/yousan/fix-button-color
修正が完了したらホットフィックスブランチに対してPRを作成する
hotfix/v1.4.19 <------ hotfix/202004/yousan/fix-button-color
ホットフィックスをmasterに適用させる際、git flowの手順に従ってホットフィックスを終了させ、masterとｄevelopにマージする。
タグとバージョン
バージョン情報をつけています。
GitFlowのリリース機能でタグを付けた場合、GitHubで自動的にバージョン番号がついてリリースとして取り扱われます。
このバージョンをつけておくことで、システム側に自動的にバージョン番号を取ったりしています。便利！
システムを継続して開発する場合にはバージョン情報を自動で付けると良かったです - Qiita
https://qiita.com/yousan/items/cffa19f67f225097127d
ブランチを作成するときはdevelopから
普段のワークフローは下記のようになります。
- developからfeatureブランチを作成
- featureブランチで作業
- PR作成
- マージ
で、いくつかのfeatureをまとめてリリースを行います。
例外への許容
developへの直コミット
GitFlowでは基本的にdevelop直接コミットを許可していません。
GitHub（やBitBucket）ではdevelopへのコミット禁止ですとか、PRマージの際にレビューが完了していないとだめだとか、その他にも色々とルールを設けることが出来ます。
大きめの開発だとdevelopへの直コミは禁止しておくほうがよいですが、ですが僕のチームではある程度許容しています。
ただし単純なファイルの追加やGit以外での修正の反映などにとどめています。
コードの変更を許容することは規律が乱れてしまうので、手間と規律のトレードオフとなります。
ブランチの再利用
マージが済んだブランチは削除しています。
基本は1つのIssueに対して1つのブランチを作成し、マージされたら削除としています。
ただしGitHub側で削除されたブランチをそのままローカルで使うこともできます。
コミット、プッシュ、PRの作成を行うと連続してブランチは生き続けます。
ブランチ名との乖離（fix-adminという名前なのにフロントの修正をしている）がなければこれでもOKです。
また開けっ放しのブランチはdevelopとコンフリクトを起こしやすくなるので、コンフリクトが頻発するようであれば規制するなど、こちらも運用しながらある程度のルール化が必要となります。
名前
- git-flow
- Git flow
- Git Flow
- Gitflow
- git flow
[Gitflow Workflow | Atlassian Git Tutorial]
(https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)