【Git】git-flowとGitHub-flowの違いについて
目次
- git-flow
 - 最初はからのコミットか始める
 - すべての機能の開発はdevelopブランチからの分岐によって開始する
 - developブランチがリリースできる段階のクオリティになったらreleaseブランチにマージする
 - リリース後の後始末
 - リリース後に見つかったバグの修正はmasterブランチから分岐する
 
git-flow
masterとdevelopブランチは消去されることがないmasterブランチに含まれるのは、製品としてリリースしたコードdevelopブランチに含まれるのは、今後リリースされる予定のコード- 開発途中ではあるが、単体の機能としてある程度完成されていたり、製品として組み込む予定ので完成している機能が組み込まれたブランチ
 
最初はからのコミットか始める
--allow-emptyスイッチを使用して、ファイルの無いコミットをする。- git-flowの
masterとdevelopブランチの始点になるコミットになる 
- git-flowの
 
すべての機能の開発はdevelopブランチからの分岐によって開始する
- 新機能開発時は新しいブランチを
developから分岐させて作成する - コードの組み込み準備が完了したら、
develpにマージする- マージ時は
fast-forward mergeを行わないように--no-ffスイッチをつける 
 - マージ時は
 developへのマージ後は使用していた新機能開発ブランチを消去する
developブランチがリリースできる段階のクオリティになったらreleaseブランチにマージする
- developブランチで
単体テストや簡易的な結合テストが完了したら、developブランチをreleaseブランチを作成してそこにマージする - releaseブランチでは、最終テストやその他のバグの修正でコミットを追加することができる
- 本格的なテストのバグ修正は
releaseブランチで行うことになる 
 - 本格的なテストのバグ修正は
 - すべてのコードの修正が終わり次第、
masterにマージするmasterブランチで表示されるコミットは、リリースしたコードのみ(修正コミットは入っていない)- マージ時は
fast-forward mergeを行わないように--no-ffスイッチをつける 
 masterブランチのリリースコミットにはタグをつけることが規約で決まっている
リリース後の後始末
- releaseブランチには、修正コミットが入っている可能性があるので、
developブランチへのコミットをdevelopブランチへマージする- マージ時は
fast-forward mergeを行わないように--no-ffスイッチをつける 
 - マージ時は
 masterブランチ,developブランチにマージが完了した、releaseブランチは消去する
リリース後に見つかったバグの修正はmasterブランチから分岐する
- リリースしたコードを修正したい場合、masterブランチのリリースコミットから分岐したブランチを作成する
- この時のブランチの名前は
hotfix-xxxにするという規約がある 
 - この時のブランチの名前は
 - 修正後は、
masterブランチ,developブランチにマージを行い、hotfix-xxxブランチは消去する 
【Git】git-flowとGitHub-flowの違いについて
https://daiki-iijima.github.io/2021/03/23/【Git】git-flowとGitHub-flowの違いについて/




