web-dev-qa-db-ja.com

Mercurialブランチを閉じるための最良の方法は何ですか?

最初にブランチを閉じてからデフォルトのブランチ(たとえば)とマージするのが良いですか、それとも最初にマージしてから閉じるのが良いですか?

たとえば、TortoiseHgでは、最初のケースでは、近いノードからデフォルトのブランチへの線が表示されます。 2番目のケースでは、最後のコミットからデフォルトブランチへの行と、最後のコミットからクローズノードへの追加の行が表示されます。

はっきりしているといいのですが。多分それは好みの問題です...

19
Lieven Cardoen

名前付きブランチについて話すとき、少なくとも最近のバージョンのMercurialでは、2つの方法に実際の違いはありません。 1.5(?)より前は状況が異なりましたが、純粋にhg headshg branchesがこれらの「閉じた」ブランチを出力に含めるという事実に基づいて、-cをコマンド。

ブランチを閉じるとき(hg commit --close-branchまたはTortoiseを使用)、ブランチXが閉じていることを示すフラグが変更に設定されている新しいチェンジセットを効果的にコミットすることを覚えておいてください。ブランチを簡単に更新して再-別のコミットを実行して開きます。

ただし、reopeningブランチの場合、Tortoiseに表示される「バー」は、以前に閉じられたチェンジセットに引き続き存在するため、この理由だけで、私は個人的に閉じてからマージするポリシーを選択します。 。満足しているものからマージしていることを確認する方が視覚的に有益だと思います(したがって、マージの前にブランチを閉じました)。

「匿名」ブランチとは少し異なります。マージされたときにhg branches出力に含まれないため、明示的に閉じる必要はありません。

11
icabod

これは好みの問題ではなく、違いがあります。つまり、ブランチを閉じてから、mergeします。

Mercurialのブランチ名は、各チェンジセットの単なる「メタデータ」です。 hg branchesが閉じたコマンドを省略したり、hg Pushがデフォルトでブランチごとに新しいヘッドを追加できないようにするなど、特定のコマンドの結果に影響します。しかし、繰り返しますが、それはフィルタリングです。

内部的には、Mercurialはリポジトリをチェンジセットのグラフ、具体的には [〜#〜] dag [〜#〜] と見なします。また、そのグラフのトポロジヘッドは、ロジックの実装に使用されます。たとえば、hg pull中にローカルリポジトリとリモートリポジトリを比較します。トポロジカルヘッドの数が多いと、パフォーマンスに影響を与える可能性があります(わずかですが、それでも)- 閉じたブランチはMercurialのパフォーマンスにどのように影響しますか? 。同様に、それらの特定の数は、IISサーバー- https://bitbucket.org/site/master/issue/8263/http)で実行されているMercurialから400 Bad Requestを引き起こす可能性があります-400-bad-request-error-when-pulling

最初にマージしてから閉じると、ブランチは閉じます-大丈夫です。デフォルトでは、人間はそのブランチを認識しません。しかし、Mercurialは別のトポロジーの頭を取得します。視覚的な説明については、以下をご覧ください。したがって、最初に閉じます。

close then merge                merge then close
----------------                ----------------

@    default, head              @    default, head
|                               |
o    merge              <-->    | x  close branch, head
|\                              | |
| x  close branch       <-->    o |  merge
| |                             |\|
o |  dev on default             o |  dev on default
| |                             | |
| o  dev on branch              | o  dev on branch
| |                             | |
| o  open branch                | o  open branch
|/                              |/
o    default                    o    default

この結論に至った経緯の詳細については、 ここ をご覧ください。

23
Ilia Barahovski

私の会社が最近発見したように、それらを近づけることを好むかなりの理由があります。他の回答で説明されているように、merge-then-closeでは、余分な「トポロジカルヘッド」が発生しますが、close-then-mergeでは、この余分なヘッドを残しません。

これらの余分なヘッドが合計されます 、最終的に同期操作で問題が発生する可能性があります(Mercurialは、プッシュまたはプルするチェンジセットを検出するために、どちらのヘッドがどちら側にあるかをネゴシエートする必要があります)。ぶら下がっているトポロジカルヘッドの数が増えると、これらの操作はどんどん大きくなり、最終的には 失敗し始めます になります。ありがたいことに、かなり簡単にできます 後でクリーンアップする しかし、そもそも問題を回避するのがおそらく最善です。

2
Chris Phillips