2

環境：

  • 7人の開発者
  • 1 製品
  • 3 つのブランチ:
    • バージョン 3.6 (安定版)
    • バージョン 3.7 (安定版)
    • マスター（開発者）

ルールとポリシー:

  • 以前のバージョンで行われた修正は、将来のすべてのバージョンでマージする必要があります。
  • 統合は継続的です: 3.6 で何かを修正した場合は、プッシュする前に 3.7 とマスターで統合してテストする必要があります。
  • 可能であれば、コミットする前に作業をリベースして、2 日前にローカルでコミットしたものが実際に一番上に戻るようにします。これは好みの問題であり、長所と短所があることは承知していますが、これがチームとして最も気に入っていることです。

私たちの問題:

無駄なマージ操作が多すぎます。シナリオは次のとおりです。

通常の統合作業:

  • Joe と Bill は、3.6 で行われる 2 つの異なる修正に取り組んでいます。
  • Joe が完了し、pull (および rebase) します
  • Joe は 3.6 ブランチで最後にもう 1 回テストします。
  • Joe は 3.7 に切り替え、3.6 をマージします -マージ 1
  • Joe は、今度は 3.7 のコンテキストで再度テストします。
  • Joe は 3.8 に切り替え、3.7 をマージします - 2 をマージします
  • Joe は、今度は 3.8 のコンテキストで再度テストします。
  • ジョーはプッシュする準備ができています
  • ビルはほぼ同じことをしましたが、ジョーがプルした直後にプッシュしました
  • ジョーはプッシュしようとしますが、新しい頭が作成されるため、操作は失敗します

面倒な (役に立たない) マージ:

  • Joe がプルし、3.6、3.7、および 3.8 で Bill から情報を取得します。
  • ジョーは 3.6 に更新し、プルから受け取った変更をマージします -マージ 3
  • ジョーは 3.7 に更新し、プルから受け取った変更をマージします -マージ 4
  • ジョーはまだ 3.7 マージ 3.6 -マージ 5
  • Joe は 3.8 に更新し、pull - merge 6から受け取った変更をマージします。
  • ジョーはまだ 3.8 マージ 3.7 -マージ 7
  • Joe はプッシュを試み、その間誰も 3.6 にプッシュしないことを祈ります。

この種の状況を自動的にマージするための拡張機能 (またはバッチまたはプログラム) を作成することを考えています。したがって、Joe がプッシュできないことがわかった場合は、ただ走るだけMergeUpAutomagicallyです。しかし、これを修正する前に、正しいワークフローを使用していることを確認したいと思います.

4

1 に答える 1

1

私が理解していれば、同じクローンで名前付きブランチを使用しています。

各バージョン (リリース、開発) ごとに異なるクローンを使用する方が簡単だと思います。各クローンには、バージョンに関連する名前付きブランチ (および古いブランチからの変更セット) が含まれます。同期（プルとプッシュ）する「公式」クローンがあります。

利点:

  • hg update を実行して「切り替える」必要はありません (私の状況では、プロジェクトごとに異なるワークスペースを持つ Eclipse インスタンスを使用しています)。以前は同じクローンで名前付きブランチを使用していましたが、混乱していました。

  • 変更セットがどこから来たのか (名前付きのブランチ バージョン) を簡単に確認できます。また、誰かが誤って上位バージョンから古いバージョンにプッシュした場合、簡単に見つけることができます。

  • 同期はより「アトミック」です。「公式」の名前付きブランチごとにプルとプッシュを行い、「公式」の名前付きブランチ間で (古いものから新しいものへ) プルします。あなたの状況では、Bill が Joe の前にプッシュしたかもしれませんが、3.6 でそれを行う時間しかなく、Joe はより高いバージョンに同期する前にそれに気付きました (それがあなたの状況で役立つかどうかはわかりません)。また、「開発」ブランチを「リリース」ほど頻繁に同期する必要はないかもしれません。

于 2013-10-02T22:37:11.247 に答える