3

hgflowを評価しています。このモデルは、複数のリリースをサポートする方法がわからないことを除いて、私のバージョン管理のニーズのほとんどを満たしています。

しばらく前に v1.0 をリリースし、v2.0 をリリースしたばかりで、最初から hgflow を使用しているとします。まだ v1.0 を使用しているお客様から、機能の実装をリクエストされました。v1.0 の安定性のため、彼は v2.0 または v3.0 にアップグレードしたくありません。

一般化されたストリームの概念を使用する:

  • hg flow develop start 1.x (develop/1.x を作成)
  • hg flow develop/1.x:release start 1.0 (develop/1.x から release/1.0 を作成)
  • hg flow develop/1.x:release 終了 (release/1.0 をクローズし、マスターで v1.0 を作成)
  • 2.x と 2.0 について繰り返すため、v1.0 タグの後に v2.0 タグがマスターに作成されます。
  • 1.x の拡張要求が受信されました
  • hg フロー開発/1.x
  • 強化に取り組む
  • hg flow develop/1.x:release start 1.1 (develop/1.x から release/1.1 を作成)
  • hg flow develop/1.x:release finish <--- マスターの v2.0 タグの後に v1.1 タグが作成されます

hgflow モデルに従うと、マスター ストリームの v2.0 タグの後に v1.1 タグが作成される可能性があります。さらに悪いことに、v1.1 での変更により、v1.0 から v2.0 までの間に行ったさまざまな機能強化が上書きされる可能性があります。

私の質問は: 誰でも私の問題の解決策を提案できますか? どんな提案でも大歓迎です。ありがとう。

4

1 に答える 1

9

この状況で使用するワークフローは、サポートストリームと関係があります。

hg flow master                       # Update the workspace dir to the master branch.
hg flow support start 1.x -r v1.0    # Create a support/1.x branch from v1.0 snapshot.
hg flow support/1.x start feature1   # Create a support/1.x/feature1 branch.
...                                  # Commits to implement feature1
hg flow support/1.x finish           # Finish feature1. Changes in support/1.x/feature1 will be merged into the support/1.x branch.
hg tag v1.1                          # Create support releases in the support/1.x branch.

1.x リリースをサポートするためのすべての変更は、support/1.x ブランチにあり、概念上、通常は他のストリームにマージされません。

于 2012-12-24T23:28:24.733 に答える