17

これはベストプラクティスの質問であり、答えは「状況によって異なります」と予想されます。もっと現実世界のシナリオとワークフローを学びたいと思っています。

まず、同じプロジェクトのさまざまな変更について話しているので、サブレポは使用しないでください。

hgリポジトリにコードベースがあるとしましょう。複雑な新機能Aの作業を開始すると、信頼できるテスターから複雑なバグBが報告されます（テスターがいますよね？）。

B（の修正）がAに依存している場合、それは簡単です。単純にci A、次にciBです。

私の質問は、彼らが独立しているときに何をすべきかということです（または少なくとも今はそう思われます）。

私は次のように考えることができます：

  1. Bには別のクローンを使用します。
  2. 同じリポジトリで、匿名または名前付きのブランチ、またはブックマークを使用します。
  3. MQを使用します（Aの上にBパッチを付けます）。
  4. 分岐MQを使用します（後で説明します）。
  5. 複数のMQを使用する（1.6以降）

1と2は、わずかに関連する質問からリンクされた@SteveLoshによる優れたブログでカバーされています。

1が他の選択肢よりも優れている点の1つは、ファイルが物理的に分離されて独立しているため、ある作業から別の作業に切り替えるときに再構築が不要なことです。したがって、たとえば、Aおよび/またはBがトライステートブール値を定義し、数千のCファイルにインクルードされているヘッダーファイルにアクセスする場合、これが実際に唯一の選択肢です（このようなレガシーコードを見たことがないことを教えてください）。ベース）。

3はおそらく（セットアップとオーバーヘッドの点で）最も簡単であり、Bが小さいか緊急の修正である場合は、AとBの順序を逆にすることができます。ただし、AとBが同じファイルにアクセスすると、注意が必要になる場合があります。AとBの変更が同じファイル内で直交している場合に適用できなかったパッチハンクを修正するのは簡単ですが、概念的にはまだ少し危険です。

4はめまいを起こす可能性がありますが、最も強力で柔軟性があり、スケーラブルな方法です。進行中のパッチにマークを付けてプッシュ/プルしたいので、デフォルトhg qinitでを使用しますが、MQリポジトリでも分岐できることを理解するには概念的な飛躍が必要です。-c手順は次のとおりです（mq = hg --mq）。

  1. hg qnew bugA; Aに変更を加えます。hg qref
  2. mq branch branchA; hg qci
  3. hg qpop; mq up -rtip^
  4. hg qnew bugB; Bに変更を加えます。hg qref
  5. mq branch branchB; hg qci
  6. Aに再度取り組むには：hg qpop; mq up branchA; hg qpush

非常に多くのステップを踏むのはおかしなことに思えます。仕事を切り替える必要があるときはいつでも、そうしなければなりませんhg qci; hg qpop; mq up <branch>; hg qpush。ただし、これを考慮してください。同じリポジトリに複数の名前付きリリースブランチがあり、それらすべてに対して同時に複数のプロジェクトとバグ修正に取り組む必要があります（この種の作業には保証されたボーナスを取得する方がよいでしょう）。他のアプローチではすぐに迷子になります。

今、私の仲間のhg愛好家、他の/より良い選択肢はありますか？

（更新）qqueue＃4はほとんど時代遅れになります。ここでSteveLoshのエレガントな説明を参照してください。

4

3 に答える 3

7

Mercurialがその仕事をすることができるので、私は常に名前付きブランチを使用します。プロジェクトの履歴を保持し、ソースコードにどの順序でどの変更を加えたかを覚えておくためです。私の作業スタイルを考えると、ディスク上に1つのクローンを配置するか2つのクローンを配置するかは、一般的に簡単です。少なくとも次の点に注意してください。

  1. プロジェクトにビルドプロセスがないため、ソースコードから直接テストして実行できますか？hg upそうすると、クローンを1つだけ作成し、別のブランチで作業する必要があるときに前後に移動したくなるでしょう。

  2. ただし、ビルドアウト、virtualenv、またはその他の構造がビルドされ、2つのブランチ間で分岐する可能性があるhg up場合、ビルドプロセスが再実行されるのを待ってから実行することは、特にセットアップなどの場合、大きな問題になる可能性があります。サンプルデータベースが含まれます。その場合、私は間違いなく2つのクローンを使用します。1つはトランクの先端にあり、もう1つは緊急機能ブランチの先端にあります。

于 2010-09-16T12:54:55.483 に答える
3

私が質問に挙げたものよりも多くの、またはより良い選択肢はないようです。だからここに再びあります。

  1. プロジェクトごとに1つのクローンを使用します。
    • 長所：完全に分離されているため、プロジェクトを切り替えるときに再構築できません。
    • 短所：ツールチェーンは2つのクローンを切り替える必要があります。
  2. 同じリポジトリで、匿名または名前付きのブランチ、またはブックマークを使用します。
    • 長所：標準のhg（または任意のDVCS）プラクティス。クリーンでクリアな。
    • 短所：切り替える前にコミットし、後で再構築する必要があります。
  3. プロジェクトごとに1つのパッチ（または複数の連続するパッチ）でMQを使用します。
    • 長所：シンプルで簡単。
    • 短所：qrefresh切り替える前に、後で再構築する必要があります。プロジェクトが直交していない場合、トリッキーでリスクがあります。
  4. qqueueプロジェクトごとに 1つのMQブランチ（または1.6以降）を使用します。
    • 長所：非常に柔軟でスケーラブル（同時プロジェクトの数に対して）
    • 短所：切り替える前に、切り替えてから再構築する必要がqrefreshあります。qcommit複雑に感じます。

いつものように特効薬はないので、仕事に適したものを選んでください。

（更新）MQが大好きな人にとっては、通常のブランチ（＃2 +＃3）の上でMQを使用するのが、おそらく最も一般的で好ましい方法です。

2つのブランチにベースラインを持つ2つの同時プロジェクトがある場合（たとえば、次のリリースと現在のリリース）、次のようにそれらの間を移動するのは簡単です。

hg qnew; {coding}; hg qrefresh; {repeat}
hg qfinish -a
hg update -r <branch/bookmark/rev>
hg qimport -r <rev>; {repeat}

最後のステップとして、チェンジセットの行を一度にインポートするオプションをqimport追加する必要があります。マイスターガイスラー-aがこれに気づいたことを願っています:)

于 2010-10-30T03:05:20.093 に答える
1

したがって、問題は、機能Aの作業を停止し、独立した機能Bを開始するように指示された時点で、次のような代替オプションがあります。水銀との並行開発を管理する方法。

スレッデッドコードを書くのと同じ方法で、並行性が削除された問題を見てみましょう。与えられた問題を解決するための簡単なワークフローを定義し、それを各問題に適用します。完了したら、Mercurialが作業に参加します。したがって、プログラマーAは機能Aに取り組みます。プログラマーBは機能Bに取り組みます。どちらもたまたまあなたです。（マルチコアの頭脳があれば:)

Mercurialがその仕事をすることができるので、私は常に名前付きブランチを使用します。プロジェクトの履歴を保持し、ソースコードにどの順序でどの変更を加えたかを覚えておくためです。

ブランドンの感情には同意しますが、機能Aがテストされていないことを彼が見落としていたのではないでしょうか。最悪の場合、コードはコンパイルされて単体テストに合格しますが、一部のメソッドは以前の要件を実装し、一部のメソッドは新しい要件を実装します。以前のチェックインとの違いは、機能Aで軌道に戻るために使用するツールです。

機能Aのコードは、通常チェックインする時点にありますか？機能Aから機能Bでの作業に切り替えることは、コードをヘッドまたはブランチにコミットする理由ではありません。テストをコンパイルして合格するコードのみをチェックインしてください。私の理由は、プログラマーCが機能Cを開始する必要がある場合、このブランチのフレッシュチェックアウトはもはや開始するのに最適な場所ではないからです。ブランチヘッドを正常に保つことは、より信頼性の高いバグ修正により、迅速に対応できることを意味します。

目標は、（テストおよび検証された）コードを実行することです。そのため、すべてのコードを（開発ブランチとレガシーブランチの）ヘッドにマージする必要があります。私のポイントは、分岐が非効率的に使用されているのを見たことがあるようです。コードが古くなり、使用されなくなると、マージは元の問題よりも難しくなります。

あなたのオプション1だけが私には意味があります。一般に：

  1. 他の誰かがそれを見る前に、あなたはあなたのコードが機能すると考えるべきです。
  2. 枝より頭を好む。
  3. 他の誰かが問題を拾っている場合は、分岐してチェックインします。
  4. 自動システムまたはテスターがコードのみを必要とする場合は分岐します。
  5. チームの一員である場合は、問題に取り組んでいる場合は分岐します。それを頭と考えてください。1-4を参照してください。

構成ファイルを除いて、ビルドプロセスはチェックアウトと単一のビルドコマンドである必要があります。新しいプログラマーがプロジェクトに参加するよりも、クローンを切り替えるのはそれほど難しいことではありません。（私のプロジェクトにはここでいくつかの作業が必要であることを認めます。）

于 2010-09-30T19:36:31.500 に答える