最初にブランチを閉じてからデフォルトのブランチ (たとえば) とマージするか、最初にマージしてから閉じる方が良いですか?
たとえば TortoiseHg では、最初のケースでは、近いノードからデフォルト ブランチへの線が表示されます。2 番目のケースでは、最後のコミットからデフォルト ブランチへの行と、最後のコミットからクローズ ノードへの余分な行が表示されます。
私がはっきりしていることを願っています。好みの問題なのかな…
最初にブランチを閉じてからデフォルトのブランチ (たとえば) とマージするか、最初にマージしてから閉じる方が良いですか?
たとえば TortoiseHg では、最初のケースでは、近いノードからデフォルト ブランチへの線が表示されます。2 番目のケースでは、最後のコミットからデフォルト ブランチへの行と、最後のコミットからクローズ ノードへの余分な行が表示されます。
私がはっきりしていることを願っています。好みの問題なのかな…
これは好みの問題ではなく、違いがあります。つまり、ブランチを閉じてからマージします。
Mercurial のブランチ名は、各変更セットの単なる「メタデータ」です。hg branches
閉じたコマンドを省略したりhg push
、デフォルトでブランチごとに新しいヘッドを追加できないようにするなど、特定のコマンドの結果に影響します。しかし、繰り返しますが、それはフィルタリングです。
内部的には、Mercurial はリポジトリを変更セットのグラフと見なし、DAGは特定のものです。また、そのグラフのトポロジー ヘッドは、ロジックの実装に使用されます。たとえば、hg pull
. トポロジー ヘッドの数が多いと、(わずかではありますが) パフォーマンスに影響を与える可能性があります -閉じたブランチは Mercurial のパフォーマンスにどのように影響しますか? . 400 Bad Request
また、IIS サーバーで実行されている Mercurialが原因で特定の数が発生する可能性があります - https://bitbucket.org/site/master/issue/8263/http-400-bad-request-error-when-puling。
1 つが最初にマージされてから閉じられると、ブランチは閉じられます - 大丈夫です。デフォルトでは、人間はそのブランチを認識しません。しかし、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
この結論に至った経緯の詳細については、こちらをご覧ください。
私の会社が最近発見したように、close-them-merge を好むかなりの理由があります。他の回答で説明したように、マージしてから閉じると、余分な「トポロジカルヘッド」ができますが、閉じてからマージすると、この余分なヘッドが残りません。
これらの余分なヘッドが加算され、最終的に同期操作で問題が発生する可能性があります (Mercurial は、プッシュまたはプルする変更セットを検出するために、どのヘッドがどちら側にあるかをネゴシエートする必要があります)。ぶら下がっているトポロジー ヘッドの数が増えるにつれて、これらの操作はますます大きくなり、最終的には失敗し始めます。ありがたいことに、後で簡単にクリーンアップできますが、最初から問題を回避することをお勧めします。