2

機能とバグ テストを停止するために使用するソース管理ブランチがある場合 (バグを修正するためにこのブランチに追加のコミットを行うことを含む)、それは何と呼ばれるべきですか?

「リリース候補」は適切ですか？

私の考えでは、そのようなブランチは「リリース」と呼ばれ、「候補」という言葉を使用することは、それが不変であることを意味します。候補 1 と候補 2 を持つことができますが、これらの特定の候補は決して変更しないでください。すなわち。候補1にはコミットがなく、何らかの方法で変更されます。

私がこれについて話し合っていた人は非常に頭が悪いので、リンクや例は素晴らしいでしょう.

関連する質問:リリース候補をプロモートするための仕様はありますか? (完成した RC がどのように考慮されるかをカバーします)

4

1 に答える 1

1

これはまだ最終的な統合ステップと見なすことができます (その中で、「不変」ではありません)。

これはあなたがまだいる場所です：

  • 次のリリースに入ることが承認された機能を統合します。
  • 統合テスト後に現れるバグの修正 (SIT - システム統合テスト、および UAT、ユーザー受け入れテスト)

「RC」は、今説明したよりもさらに安定していると考えることができますが、ショーストッパーのバグを修正することもできます。
その意味で、「候補 1」と「候補 2」は (同時に) ありません。RC は通常、連続しています。

次に、「リリース」ブランチは、ポスト プロダクション (ホット フィックスとリリース メンテナンス) 用です。
本番環境に移行するときにアプリケーションの状態を凍結し、開始点でそれを使用して本番環境を維持します。

要するに：

  • ブランチは不変ではありません:開発ライフサイクルにおける開発作業を分離します。
    コミットを追加する必要があります。どのブランチでも。
  • タグ(または「ラベル」、「ベースライン」、または...)は不変です: 特定の時点でコードの特定の状態をフリーズします。
于 2012-12-06T22:27:25.203 に答える