Gitflowの完成した機能の「定義」とは何ですか？
これはGitflowプロセスの質問です。私がGitflowについて読んだすべてのドキュメント（および図）では、機能が完了するとそれが開発ブランチにマージされることを常に示しています。
しかし、どこにも定義されていないことが1つあるのは、「完成した機能」の定義です。テスト（Quality Assurance、User-Acceptance-Testingなど）は機能ブランチ自体で行われるべきですか、または開発者は実装が完了したと判断したらすぐに（ただし、 QA/UAT承認）？
論理的には、QA/UATが機能ブランチ自体で発生することを期待します。そうしないと、質の悪いコードが開発ブランチに入り込み、他の開発ブランチを汚染する可能性があるという単純な理由があります。
しかし、それが事実である場合、それは各新機能が他の機能とは独立してテストされ、すべてがマージされて初めて完全な回帰テストが複数の機能にわたって発生することを意味しますか？完全な回帰テストは、リリースブランチが作成された後にのみ実行する必要がありますか？
この機能は、完成して開発ブランチにマージされる前に、単体でテストする必要があります。ただし、gitflowを使用して終了の意味を定義するのは、各チーム次第だと思います。各チームは、機能ブランチで実行する必要があるテストの量と、開発ブランチにマージして戻った後に実行する必要があるテストの量を決定する必要があります。
機能ブランチと開発ブランチの両方でテストを行う必要があります。開発ブランチは、機能ブランチを作成したときとは異なる状態にあると想定するのが妥当です。つまり、機能を終了した後、開発ブランチの新しいテストラウンドが必要になります。
開発ブランチに加えられた変更とは別に機能をテストする場合、機能の終了後にバグがある場合は、これらのテスト結果を使用して、コードのデバッグを行う場所に集中できます。
機能ブランチでどのくらいのテストが行われるかは、実際にはあなたとあなたのチーム次第です。ただし、機能が開発ブランチにマージされた後は、開発ブランチで完全なテストを行う必要があります。これにより、完全なUATを実行せず、機能ブランチの単体テストのみに依存するなど、テストを少なくすることができます。または、他の量のテストを意味する場合があります。
チームは「完了」した機能を検討するためのさまざまな基準を持っていますが、この部分は一般的にdeveloperが完了したときと見なされます。だからといって品質が落ちるわけではありません。私のチームでは、コードレビューに合格し、単体テストのカバレッジが100％あり、自動統合テストがあり、これらのテストはすべて成功しています。
その理由は、ブランチを分離しすぎるとコストがかかるためです。 developにマージするまでの時間が長いほど、重大な競合のリスクが高くなります。また、完全に確認するのが難しい大きなプルリクエストがあります。機能ブランチの理想的な寿命は、数日以内です。
複数のチームがその速度で作業しているため、異常に大きなQA組織がない限り、そのサイクルタイムはQAで処理するには速すぎます。プラグマティズムの問題として機能を集約するブランチからビルドを提供する必要があります。 gitflowモデルでは、これは通常releaseブランチだと思います。
作業をやめるときです。あなたはあなた自身の基準を考え出さなければならないでしょう。うまくいけば、あなたがやめようとするあなたの決定は、あなたが要件を満たしたか、またはあなたがやめたことをやめたことです。また、追加の要件がある場合、または要件が変更されている場合は、システムの使用方法を決定する必要があります。
Gitflowがツールを提供するだけなのか、ソフトウェア開発の管理に関する特定の方法論を意図しているのかを判断するのに十分な知識はありません。ほとんどのハンマーは、どの釘を打つべきか、どれほど硬いか、どのくらい深いかを教えてくれません。