Лучше ли сначала закрыть ветвь, а затем объединить ее с ветвью по умолчанию (например) или сначала слить ее, а затем закрыть?
Например, в TortoiseHg в первом случае вы увидите строку из закрытого node в ветку по умолчанию. Во втором случае вы увидите строку от последнего фиксации к ветки по умолчанию и дополнительную строку от последней фиксации к закрытию node.
Надеюсь, я поняла. Может быть, это вопрос вкуса...
Нет никакой реальной разницы между этими двумя методами, когда речь идет об именованных ветвях, по крайней мере, в любой новой версии Mercurial. Все было по-другому до 1.5 (?), Но только в том, что hg heads и hg branches будут включать эти "закрытые" ветки в их выходе - они все еще могут, если вы укажете -c в команде.
Помните, что когда вы закрываете ветку (используя hg commit --close-branch или в Tortoise), вы просто просто фиксируете новый набор изменений, в котором у изменения установлен флаг, указывающий, что ветвь X закрыта - вы можете легко обновить ветвь и повторно -открыть его, выполнив другое коммит.
Однако при повторном открытии ветки "бар", который вы видите в Tortoise, по-прежнему будет существовать в ранее закрытом наборе изменений, и поэтому по этой причине я лично предпочел бы политику close-then-merge. Я думаю, более визуально поучительно видеть, что вы слились с чем-то, чем вы были довольны (и, следовательно, закрыли ветвь до слияния).
Вещи немного отличаются от "анонимных" ветвей, поскольку они не включены в вывод hg branches, когда они были объединены, и поэтому не требуют явного закрытия.
Это не вопрос вкуса и разницы. Короче говоря, закрыть ветвь, затем слить.
Дело в том, что имена доменов Mercurial - это просто "метаданные" для каждого набора изменений. Это влияет на результаты некоторых команд, таких как hg branches опускает закрытые, или hg push запрещает добавление нового заголовка в ветвь по умолчанию. Но опять же - это фильтрация.
Внутри Mercurial видит репозиторий как график наборов изменений, DAG. И топологические головки этого графика используются для логической реализации, например, при сравнении локальных и удаленных репозиториев во время hg pull. Большее количество топологических головок может (слегка, но все же) повлиять на производительность - Как закрытые ветки влияют на производительность Mercurial?. Также определенное число из них может вызвать 400 Bad Request из Mercurial, запущенного на сервере IIS, - https://bitbucket.org/site/master/issue/8263/http-400-bad-request-error-when-pulling.
Когда первый слияние и затем закрываются, ветка закрыта - все в порядке, и человек не видит эту ветвь по умолчанию. Но ртуть получает еще одну топологическую голову. Посмотрите ниже для визуального объяснения. Следовательно, сначала закройте.
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
Вы можете посмотреть здесь для получения подробной информации о том, как мы пришли к такому выводу.
Как недавно узнала моя компания, есть довольно веская причина предпочесть близкое им слияние. Как обсуждали другие ответы, в merge-then-close вы получаете дополнительную "топологическую головку", тогда как при близком слиянии вы не оставляете эту дополнительную голову позади.
Оказывается, эти дополнительные главы складываются и могут в конечном итоге вызвать проблемы при выполнении операций синхронизации (где Mercurial необходимо согласовать, какие главы находятся на какой стороне, чтобы обнаружить изменения нажимать или тянуть). По мере того, как число болтающихся топологических голов растет, эти операции становятся все больше и больше, до тех пор, пока в конце концов они не сработают. К счастью, вы можете легко очистить их позже, но, вероятно, лучше всего избежать проблемы в первую очередь.