0

(これは、cvs で標準開発と顧客固有の開発を管理する方法に関する私の以前の質問へのフォローアップの質問です。)

標準開発(標準ソフトウェアの開発) と顧客固有の開発mercurial(標準ソフトウェアの顧客固有の変更の開発)を区別するために、さまざまなブランチを使用しています。

したがって、次のブランチがあるとしましょう。

  • デフォルト(標準開発ブランチ)
  • リビジョン1.0 (バグ修正のための標準開発ブランチ)
  • リビジョン1.1 (バグ修正のための標準開発ブランチ)
  • customerA (「revision1.0」からのクローンで、いくつかの変更が加えられています)

顧客 A が 1.0 から 1.1 にアップグレードしたい場合、リビジョン1.1から顧客A にプルする(そしてマージの競合を解決する) だけです。ここまでは順調ですね。

私が避けたいのは、開発者が誤って顧客固有のコードを標準の開発ブランチにマージすることです。「顧客固有のコード」は、その Java 名前空間によって識別できます。

これを行う方法はありますか？

編集：これは正しい用語であるため、「プッシュ」を「マージ」に変更しました

4

3 に答える 3

1

開発者が不正なコミットやマージを「中央」リポジトリにプッシュするのをブロックすることはできますが、それらをローカルで実行するのを止めることはできません。したがって、たとえばpretxnchangegroupフックを使用して、プッシュがブランチ (またはクローン) で顧客固有のコードにならないようにすることができますrevision1.0が、それは開発者のプッシュを拒否するだけです。彼または彼女はまだローカルに悪いコミットを持っているので、それを解明する必要があります。

用語を混同しているため、上記のコメントには混乱があります。(名前付き) ブランチ間で物事をマージし、リポジトリ間で物事をプッシュします。

于 2013-10-16T19:55:16.800 に答える
0

これは実際には質問に対する答えではありませんが、クローンの代わりに分岐を使用している場合、私の謙虚な意見では、この問題について心配する価値はありません。

開発者がリビジョン番号ではなくブランチ名を使用してブランチをマージし、顧客ブランチのブランチ名が他のブランチとかなり区別されている限り、誰かが誤って 'hg merge customerA' を実行することは非常に困難です。私たち (12 人の開発者チーム) は、同様の分岐戦略を数年間実行してきましたが、誰かが間違った分岐を誤ってマージしたことはまだありません。

まれに発生する場合がありますが、通常はリバース コミットを使用して 1 ～ 2 時間で解決できます。また、customerA を何にもマージしていないように見えるので、そのブランチでリバース リバース コミットを実行して、変更を元に戻すこともできます。

于 2013-10-16T20:58:45.360 に答える
0

プッシュをまったく許可しないことで、偶発的なプッシュを防ぐことができます。メイン（おそらく「チーム」）リポジトリの賢明な管理者がいると仮定すると、プルリクエストのみを使用することに頼ることができます。これによりプッシュが防止され、メイン リポジトリの管理者のみがメイン リポジトリにプルする権利を持ちます。または、容認できる形にならないように見える場合は、拒否します。

Pieter Hintjens は、専用のリポジトリの使用を提案しています (目的ごとに 1 つのリポジトリがあるため、1 つのリポジトリがブランチの役割を果たす可能性があります)。彼がこの組織を作った理由の 1 つは、リポジトリへのプッシュによって発生する偶発的な混乱を防ぐためです。http://hintjens.com/blog:24の「競合における堅牢性」および「分離の保証」を参照してください。

Mercurial はブランチ名をコミットに焼き付けておくため、これは git よりも Mercurial の使用に少し適しているように思われることに注意してください。

于 2013-10-17T00:44:35.423 に答える