0

中央のMercurialリポジトリと、このリポジトリにアクセスできる複数のチームがある場合、すべてのチームは時々、変更を中央のリポジトリに同期する必要があります。

チーム A とチーム B が状態にあり、中央リポジトリにプル/マージ/プッシュする意図があるとします。

A pulls.
B pulls.
A merges
B merges.
B pushes. => A has to pull and merge again before pushing!

この競合を回避する (おそらく技術的な) 方法はありますか? もしかして何かのロック？それとも、これは人が生きなければならないものですか？:-)

ちなみに、この「衝突」はチーム内でも小規模に発生します。しかし、チームメンバーは同じ部屋にいるので、衝突を避けるために部屋全体で自分の意図を「叫ぶ」だけでこれを解決できます.

4

2 に答える 2

3

プルするときに使用する最も簡単な方法hg pull --rebase- これは、ローカルの変更をメイン リポジトリからの変更の上にリベースし、マージが多すぎるのを回避します (ただし、これは実際には Mercurial では問題ではありませんが、試している開発者にとっては問題になる可能性があります)。歴史を理解するために）。

あなたの例では、に変更B mergesするB rebasesと、 A は引き続きプルして再度マージする必要がありますが、従うべき名前のないブランチは少なくなります。

いずれにせよ、プルの後にリベースするかマージするかに関係なく、すべての人が変更を利用できるように、すぐにプッシュすることをお勧めします。

しかし、繰り返しになりますが、この「問題のある」シナリオは、開発者にとって不便なため、問題があるだけであることを強調したいと思います。これは実際、Mercurial のような DVCS が処理するように設計されているワークフローです。「標準的な」ワークフローは、プッシュする前に常に「プルしてマージ/リベース」することでした。そのため、マージせずにプッシュしようとすると、新しいヘッドが作成されるという Mercurial の警告が表示されます。

于 2013-07-28T10:50:15.047 に答える
1

通常はそれで生活できますが、私見では、この方法で作業するのは常識です。

回避策はありますが、ブランチの意味を誤用しています。

  • A と b はブランチを作成し、tip/default/master はそのままにします。
  • どちらも変更をコミットしてプッシュできますが、これにより中央リポジトリにブランチが作成されます。
    • 命名規則が同じ場合、深刻な競合が発生する可能性があります。命名規則が役立つ場合があります。
  • 誰か、主にビルド​​ エンジニアまたはシステム アーキテクトが、異なるブランチからの変更をマージする必要があります。

両方が同じコンポーネントの異なる機能に取り組んでいる場合は、そうするのが良い方法かもしれません。

この章http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.htmlを読むことをお勧めします。

于 2013-07-28T10:47:06.813 に答える