Может Подвижное слияние именованное ответвление, которое не является головой?
Eric Evans и шведская консалтинговая компания выпустили пример приложения на основе поставлющегося примера, который Eric использует всюду по книге. Это находится в Java, но понятия хорошо документируются на странице проекта.
http://dddsample.sourceforge.net/
Однако быть предупрежденным, что DDD больше о поездке, чем место назначения. Поймите, что пример кода, Вы смотрите, принял много форм, прежде чем это стало тем, что Вы видите теперь. Вы не видели неловкие модели, которые использовались первоначально, и Вы пропускаете шаги, сделанные для рефакторинга основанного на модели на понимании, полученном по пути. В то время как стандартные блоки важны в DDD, Eric полагает, что они слишком подчеркнуты, поэтому возьмите все образцы с мелкой частицей соли.
2 ответа
Карл Мейер прав. Вы думаете как пользователь git, а Mercurial работает по-другому.
Вы можете сделать то, что предложил Карл, и просто принудительно сделать следующий коммит в ветке dev. Лично меня это может сбить с толку, если я это увижу, поскольку в ветке dev возникнет разрыв.
Я бы с этим справился, если снова объединить ветку функций в: hg update dev && hg merge feature && hg commit -m 'Объединить в завершенную функцию.'
В результате получился бы график вроде:
a - dev
b - dev
c - dev
d - dev
/|
e | - feature
f | - feature
\|
g - dev
Для меня это ясно показывает, что именно произошло. Вы разветвились для новой функции и по завершении добавили ее в ветку разработки. Тот факт, что пока что в dev не было других коммитов, является просто совпадением и не требует изменения рабочего процесса.
Named branches in hg (unlike in git) don't "point" anywhere. Branch names aren't movable aliases for a particular rev. Each commit has a metadata marker naming the branch that commit is on; that's all.
In this situation, if you have no separate commits descending from "d" on the dev branch, then all you need to do is run "hg branch dev" and then your next commit, descended from "f", will be back on branch dev. Which I think will achieve the results you're looking for.
EDIT: That will work, but Steve Losh's suggestion of doing an actual merge will result in a more sensible history.