GitFlowの説明
GitFlowのグラフ
GitFlowにあるブランチの説明
- masterブランチ、developブランチがメイン
- featureブランチ、releaseブランチ、hotfixブランチが補助
- masterブランチは常にリリースできる状態
- developブランチから、featureブランチを切って開発を進める
- featureブランチは機能追加用(通常の開発用)
- releaseブランチはdevelopブランチからブランチを切ってリリース直前用（例：受入テスト、総合テストのため利用）
- hotfixブランチはリリース後の緊急対応用
GitFlowの流れ
フェーズ1:開発フェーズ
1.developブランチからfeatureブランチを切って、開発
2.他の人が開発したら自分のfeatureブランチにマージ
3.開発が終わったらfeatureブランチをdevelopにマージして、featureブランチを削除
1～3を繰り返して開発を進める
フェーズ2: リリース前フェーズ(リリース準備作業)
4.開発が終了したらdevelopブランチからreleaseブランチを切ってリリース準備
5.releaseブランチでリリース前の作業を行う、releaseブランチの変更が発生場合6に行く、変更がない場合に7いく
releaseブランチの変更が発生場合
- テスト実施で不具合が出る
- 仕様変更
- 他の場合
6.releaseブランチを変更する
※ 変更が大きいの場合：
6.1 releaseブランチから新ブランチを切って、開発を行います。
6.2 新ブランチで開発が完了したら、releaseブランチにマージして対象ブランチを削除。
※ 小さい変更の場合releaseブランチに直接開発すれば構いません。
5～6を繰り返してreleaseブランチはコードフィックスまで進める
7.releaseブランチの編集完了後はdevelopブランチとmasterブランチにマージして、releaseブランチを削除
フェーズ3: リリース
8.リリース(masterブランチのデプロイ)
9.リリースタグ作成
- タグ作成方法
- Jenkinsで自動作成
- 手動で
フェーズ4: リリース後
10.リリース後、バグが発生した場合にはmasterブランチからhotfixブランチを切って対応
11.バグ対応が完了したらdevelopブランチとmasterブランチにマージして、hotfixブランチを削除
注意事項
- 作業を行うのはfeatureブランチ/releaseブランチ/hotfixブランチ上で
- developブランチ/masterブランチでは作業は行わない
目的
- チームの中にGithubのworkflowを統一する。
- 長い時間開発した後、リリースを行うようなチームに向いている
メリット・デメリット
メリット
-
ブランチ運用ミスを軽減できる
- hotfix（不具合対応）とfeature（機能開発）が明確に区別できる
- ブランチの役割は明確設定するので、マージ先のブランチを間違える等のオペレーションミスを軽減できる
-
リリースタグ作成、マージ済みブランチの削除の手順があるので、githubは綺麗にみえる
デメリット
- 複雑
- 毎日デプロイを行うようなチームには向いていません。
Github-Flowの説明
Github-Flowのグラフ
Github-flowの流れ
1.masterブランチから説明的な名前を付けたブランチを切って、開発
2.開発が終わったら、プルリクをオープンする
3.チーム内でコードレビュー、コメントしていただき、修正してpushする
4.レビューの修正が終わったら、対象ブランチを環境(開発、受入、本番)にデプロイしてみて問題がないかを確認する
- 問題がなければ5番に行く
- 問題がある場合
4.1 ロールバック：masterブランチをデプロイする
4.2 問題を対応して3番に戻ります。
5.masterブランチにマージする。
注意事項
- masterブランチは常にデプロイ可能状態です。
目的
- チームの中にGithubのworkflowを統一する。
- 毎日リリースを行うようなチームには向いている
メリット・デメリット
メリット
- 簡単に理解できる
デメリット
- 環境にどのブランチをデプロイしているの確認コースがかかる
- hotfix（不具合対応）とfeature（機能開発）が区別しないので、ブランチ運用ミスを発生する可能性が高い。
- リリースタグ切る、マージ済みブランチを削除の手順はまだありません。
まとめ
- gitflowとgithubflowの比較
- 同様 : チームの中にGithubのworkflowを統一する
- 差異 : 下記のテーブルにて確認ください
| gitflow | githubflow | |
|---|---|---|
| 目的 | ・長い時間開発した後、リリースを行うようなチームに向いている | ・毎日リリースを行うようなチームには向いている |
| メリット | ・ブランチ運用ミスを軽減できる ・リリースタグ作成、マージ済みブランチの削除の手順があるので、githubは綺麗にみえる |
・簡単に理解できる |
| デメリット | ・複雑 ・毎日デプロイを行うようなチームには向いていません |
・環境にどのブランチをデプロイしているの確認コースがかかる ・ブランチ運用ミスを発生する可能性が高い ・リリースタグ切る、マージ済みブランチを削除の手順はまだありません |