Atlassian の Web サイトで git ワークフローを見てきました。
https://www.atlassian.com/git/workflows#!workflow-gitflow
それに基づいて、UAT (ユーザー受け入れテスト) レイヤーを含む、このワークフローに関する独自のスピンを考え出しました。
また、develop から uat へ、および uat から master へとプロモートするときに、release.txt ファイルを作成してコミットするステップもあり、これが基本的に Web サイトのバージョン番号になります。
私は release.txt プロセスにあまり満足していません。タグ付けを使用したいと思いますが、ライブ サイトは azure にあるため、git からアップロードされず、個別にパッケージ化されます。
図では、コメントは作成したバッチ ファイルに関連しています。
- git nf = 新機能
- git mf = マージ機能 (開発にマージ)
- git uat = UAT のプロモート (develop を uat にマージし、release.txt を生成し、変更を develop にマージします)
- git nb = 新しいバグ修正
- git mb = マージ バグ修正 (uat にマージし、release.txt を生成し、uat を develop にマージします)
- git live = live をプロモートする (uat を master にマージし、release.txt を生成し、変更されたものを uat にマージして開発する)
- git nh = 新しいホットフィックス
- git mh = ホットフィックスのマージ (master にマージし、release.txt を生成し、uat にマージして開発)
ソリューションを設計しすぎているように感じます。ワークフロー設計に関するフィードバックをいただければ幸いです。それが役立つ場合は、バッチファイルも含めることができます