0

トランクベースの開発を行っています。最新かつ最高のコードは、UAT を取得する準備が整うまで、トランクに継続的に統合されます。その段階で、UAT のトランクからリリース候補ブランチを作成し、トランクで新しい開発を続けます。このリリース候補が UAT を通過すると、タグ付けされて Live にリリースされ、タグから作成されたメンテナンス ブランチが次のメジャー (UAT) リリースまで有効になります。

問題は、バグ修正のマージをどのように処理するかです。UAT 中にメンテナンス ブランチでバグが修正された場合、このコード修正をトランクとリリース候補にマージする必要があります。UAT 中に UAT バグが修正された場合は、このコード修正をトランクにマージする必要があります。

これは誰もが知っていますが、マージが見逃されることがあります。必要なすべてのブランチ (トランクとリリース候補) に修正が適用されていないため、Live で修正されたバグが再び表面化するケースがありました。

これを追跡するために、コミット コメント (基本的には私たち自身の貧しい人々 のマージ情報) で他のブランチへのコミットを参照し始めました。

しかし、メンテナンス ブランチへのすべてのコミットがトランクとリリース候補にマージされ、リリース候補へのすべてのコミットがトランクにマージされることを確実にする方法はありますか?

4

2 に答える 2

0

VCS がバグ修正と進行中の開発との違いを見つける方法はないため、簡単に言えば、100% 確実にする方法はないということです。違反者に発砲または発砲しても、それが起こらないことを保証するものではありません。 実際にそうすることで、再犯者を減らすことができます。

于 2013-08-23T05:11:06.207 に答える
0

常勤の場合

  • メンテナンス ブランチのすべてのコミットをトランクにマージし、候補をリリースします
  • リリース候補のすべてのコミットをトランクにマージします

（明らかに!!!）特別なポストコミットフックを使用できます

前提条件

  • トランク + RC ブランチのワーキング コピー (SVN サーバー ホスト上)

さらに、必須ではありません（下記参照）

  • フックのコードを変更せずにカスタムユーザーリストからコミットをブロック|パスできるプリコミットフック

ビジネスロジック (TBT!!!)

  • コミットが監視対象ブランチのいずれかに影響する場合 (svnlook dirs-changedこのタスクで使用): (既知の) ターゲットへのマージが必要です。この時点で、将来の必須マージのターゲットのリストを取得できます
  • 合流してみる
    • svn upターゲットの WC
    • マージしてみてください:svn merge <options> --dry-run
    • test-merge で競合がない場合 - WC でマージを実行し、マージセットをコミットし、終了コード「OK」を返し、フックを終了します
    • マージ時に競合が検出され、マージへの人間の介入が必須である場合は、任意のパスを選択できます。
      • コミッターに問題と次の待機中の操作について通知します (競合を解決してマージする)
      • コミッターに問題と彼の次の待機中の操作について通知し、何らかの方法でコミッターのユーザー名を禁止リストにドロップして、事前コミット フックを作成します (ターゲットへの手動マージセット以外の将来のコミットを禁止します)。
  • コミットがブロックされたユーザーから TARGET(s) にマージセットされている場合 - ユーザーを禁止から削除します
于 2013-08-23T09:21:37.007 に答える