13

私は 3 人の開発者のチームで働いており、最近 CVS から Mercurial に切り替えました。各ワークステーションにローカルリポジトリを持ち、開発サーバーにプル/プッシュすることで、Mercurial を使用しています。コミット後にプッシュするのを忘れがちで、3 方向のマージの競合が頭痛の種になる可能性があるため、これが最適なワークフローかどうかはわかりません。現時点では、分散型 VC の複雑さが利点を上回っているため、使用できるより良いワークフローはありますか。

ありがとう

4

5 に答える 5

10

3 方向のマージが頻繁に発生している場合は、あなたとチーム メンバーが取り組んでいることの重複が多すぎることが原因である可能性があります。Mercurial は、ファイルのまったく同じ行を編集していない限り、マージ自体の処理に優れています。可能であれば、作業をより明確に分割して、大規模なマージの頭痛の種を回避できます。また、mercurial よりもマージが劣っているため、これは CVS でも問題になることに注意してください。

また、コミットのたびにプッシュする必要もありません。ワークフローは次のようになります。

  • いくつかの機能の一部をコミットします。
  • いくつかの機能をさらにコミットします。
  • 機能の最後の部分をコミットします。
  • 愚かな間違いのバグ修正をコミットします。
  • 全機能をリポジトリにプッシュします。

ある程度、これはGoing Darkのように見えますが、上記の例の機能の範囲を小さくすることで軽減できます。

于 2010-07-02T21:51:42.900 に答える
8

  1. CVS について知っていることはすべて忘れてください。一部のコマンドが多少似ていると感じても、Mercurial は似たようなものではありません。

  2. http://hginit.com/を読んでください。例に従ってください。

  3. CVS について知っていることはすべて忘れてください。

  4. 私は真剣です。これは最も難しい部分です。ツールを信頼することを学びましょう。

于 2010-07-02T13:48:06.603 に答える
3

すべて同じブランチに変更を加えているようです。これには、ほぼすべてのコミットで互いの変更をマージしているという満足できない副作用があります。これは、プッシュするたびに手動で競合に介入する必要がないことを除けば問題ありません。

これが私が提案するワークフローです。ブランチをより頻繁に使用することを目的としているため、マスター ブランチへのマージの頻度を減らす必要があります。

  1. すべての開発者に、別のブランチですべての機能を開発してもらいます。こちらです：

    • 他の人からの変更を常にマージすることを避けます。

    • 次の人が「マージを難しくする」前に未完成の作業をプッシュするというプレッシャーから解放されます。

  2. 機能が「完了」し、変更が問題なく適用されるように見える場合 (判断の判断)、機能ブランチをマスター ブランチに直接マージし、機能ブランチを削除します。

  3. 機能がマスター ブランチよりも遅れている (多くの機能がマージされている) 場合、またはマージが難しいと思われる場合:

    1. masterを機能ブランチにマージします。

    2. バグを見つけて修正し、他の開発者から孤立して満足してください。

    3. 機能の準備ができていると仮定して、それを master にマージします (注意: この方向のマージは定義上クリーンになります)。そうでない場合は、開発を続けることができます。

于 2010-07-02T22:31:09.033 に答える
1

各ワークステーションにローカルリポジトリを持ち、開発サーバーにプル/プッシュすることで、Mercurial を使用しています。

それは私にはいいですね。私のチームは約 2 倍の規模で、うまく機能しています。

コミット後にプッシュするのを忘れがちなので、これが最適なワークフローかどうかはわかりませんが、

コミットのたびにプッシュする必要はありません。押したいときに押します。これが DVCS の大きな考え方です。つまり、コミットとプッシュは別のものです!

3 方向のマージの競合は、本当に頭痛の種になる可能性があります。

同じコード行で何度も作業していますか? 私の 5 人から 6 人のプログラマーのチームでは、1 日に数回プッシュ/プルを行い、1 日に最大数十回コミットしていますが、最後にマージの競合を手動で解決しなければならなかったのはいつか思い出せません。確かに、ここ 1、2 か月ではありません。

現時点では、分散型 VC の複雑さが利点を上回っているため、使用できるより良いワークフローはありますか。

おそらく、あなたのワークフローをもっと詳しく説明する必要があります。なぜなら、私が通常の勤務日に遭遇する集中型バージョン管理の複雑さはおそらく 1 つのコマンドだけであり、その利点は非常に大きいからです。「hg Blame」を 1 回実行するだけで、1 年中入力しなければならなかったすべての「hg push」よりも集中型バージョンよりも多くの時間を節約できます。

于 2010-07-02T23:47:14.873 に答える
0

それだけの価値はありますが、私たちは同じ規模のチームで初めて Mercurial を使用し、同じ問題から始めました。

私たちは固執し、今では状況が大幅に改善されています。ほとんどの問題は、コードベースが小さく、人々が同じことに取り組もうとしていたときに発生したと思います。もう少し確立された今、人々はお互いのつま先をあまり踏まなくなり、パリは大幅に減少しました.

あなたがそれを整理することを願っています！

于 2012-06-28T21:13:31.557 に答える