現在、私たちはGitのバージョン管理ワークフローとしてチームを編成しています。私たちは、QAでテストされ、プロダクトオーナーが受け入れたすべてのチケットを含む、毎週プロダクションデプロイメントを行う反復作業を行っています。つまり、20個のチケットをテストし、15個のチケットがQAを通過してリリースに追加される可能性があります。開発者に送付された5枚のチケットは、リリースに含まれていない可能性があります。GitFlowを使って開発版から安定版をリリースする
我々は、以下の枝持って私たちのバージョン管理で:
- 機能/ * - 彼らは仕事が行われ終了するまで、特定のチケットに取り組む開発者(複数可)、自分をコミットし、その変更をプッシュしますチケットのために。このブランチは、開発ブランチに基づいて作成され、定期的に開発からの変更を他の開発者に追いつきます。
- - このブランチでは、開発者は機能ブランチで行われた変更をマージします。また、CI環境は、最新の開発バージョンをビルドしてテスト環境に導入するために、このブランチに耳を傾けています。
- リリース/ x.x - このブランチは、製品の所有者/ UATに配信するための新しいリリースの準備に使用されます。ここに私たちの問題があります。すべてのチケットをプロダクションにリリースすることはできないので、開発からこのブランチまでのすべてをマージすることはできません。だから、現時点で私たちはすべてのものを手動でチェリーピッキングしています。すべてが整理され、多くの矛盾があるので、本当に恐ろしいことです。また、開発からすべてのものをマージすることはできませんが、行くことができないチケットを元に戻すことは持続可能な解決策のようには見えません。
- マスター - アプリケーションの安定版です。
私の最初のアイデアは、マスターブランチに基づいてフィーチャーブランチを作成することでしたが、これは開発者が常に古いバージョンのアプリケーションで開発していることを意味します。これは、プロセスの後半で統合の問題につながる可能性があります。
私はこの問題の唯一の人ではないと思います。この問題のあなたの経験は何ですか?
チェリーピッキングからリリース音が私に悪いものに発展する。ブランチ全体をマージするか、まったくマージしないでください。 –
こんにちは@私たちのリリースはそれほど規則的ではないことを除いて同じシナリオがあります。私たちは数ヶ月前にgitに移植しただけなので、私たちの環境にgit-flowを採用する方法はまだ学んでいます。あなたの質問に対する答えを読むことに興味があります。あなたの質問には本当に答えるものではありませんが、これまでは '開発 'の機能ブランチを開発し、UATの準備が整った時点で'開発/展開 'から' release/x.x'を切りました。 UAT中に作成された小さな新しい機能や修正は、 'release/x.x'ブランチから/へ分岐されます。拒否された機能は、マージコミットを手動で元に戻す必要があります。 – Rob
こんにちは@Rob、ありがとう!これは、Gitでリリースを管理するうまい方法のようです。数ヶ月からGitにも完全に変更されました。だから、組織全体の中で私たちはそれほど多くの経験を積むことができません。私は、機能を別々に完全にマージして、それが入るべきリリースにする方法を見つけたいと思っています。 –