Сообщение об ошибке слияния Hg, лучшая практика?

Я очень много делаю:

C:\Code>hg pull
pulling from http://server/FogBugz/kiln/Repo/Project/Rebuild/trunk
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 4 changes to 4 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

C:\Code>hg merge
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, dont forget to commit)

C:\Code>hg commit -m "Merged"

C:\Code>hg push
pushing to http://server/FogBugz/kiln/Repo/Project/Rebuild/trunk
searching for changes
remote: kiln: successfully pushed 2 changesets

Мой вопрос в том, что лучше/более полезное сообщение фиксации использовать после слияния pull из репозитория. Существуют ли какие-либо рекомендации, которые люди используют в распределенных системах контроля версий для такого рода вещей?

Ответ 1

Если вы используете расширение , он автоматизирует операцию pull, merge step на один шаг, выборку. Сообщение, которое оно автоматически генерирует, является чем-то вроде "автоматического слияния". Разработчики hg, похоже, считают, что это разумно, поскольку расширение теперь распространяется с базой.

Объединяющие сообщения, похоже, не содержат особо большого объема информации. Ваше сообщение кажется разумным.

[[offtopic, мы иногда используем их как возможность для каламбура по слиянию слов]]

Ответ 2

Нет такого способа, чтобы вот что я пытался придерживаться.

В сообщениях фиксации:

Jus помнит, что эти сообщения являются единственными строками, которые свяжут вас с тем, кто пытается расшифровать причины фиксации.

Ключ должен предоставить описание, которое будет полезным комментарием по разработке кода. Поэтому, когда кто-то использует hg log, у него есть хороший комментарий о том, как разрабатывается программное обеспечение.

Некоторые хорошие практики:

Свяжите его с вашей системой управления ошибками:

исправления # 3456, новая функция # 2435 и т.д.
или более описательное из того, какие изменения вносят репо
Дайте кредиты

На самом деле, я делаю в основном. смотреть на текущее состояние "hg log" и см. какое полезное сообщение означало бы логическая прогрессия в понимании последней фиксации.

Ответ 3

До тех пор, пока "слияние" в сообщении каким-то образом, мы получили удовольствие, воспользовавшись возможностью заполнить наши ртутные журналы весельем. Например, мы использовали сообщения о слиянии, такие как "кредиты на слияние недвижимости на все время" или "производство слияния Гриффина".

Ответ 4

Вы можете использовать расширение переадресации, поэтому hg pull --rebase пересортирует ваше репо на центральный репозиторий. Это отрицает необходимость слияния после вытягивания.

Я добавил для него псевдоним:

[alias]
pure = pull -u --rebase

Хорошо работает для нас.

Более подробная информация находится на странице RebaseProject.

Ответ 5

Вы можете собирать все сообщения о добавлении новых добавленных наборов изменений в файл

$ hg log --rev 'reverse(p2():ancestor(p1(),p2())-ancestor(p1(),p2()))' \
         --template '{desc}\n' \
         > commit-message.txt

затем вручную отредактируйте файл commit-message.txt и, наконец, используйте его как сообщение журнала:

$ hg commit -l commit-message.txt

Ответ 6

Для мирских слияний, где вы работаете только с одним репозиторием, я думаю, что просто "слияние" в порядке. Обычно вы даже не знаете все, что слилось, потому что все остальные люди все равно меняются.

Единственное, что я хотел бы предложить сделать более подробным, - это когда вы работаете с несколькими репозиториями. Если у вас есть devel repo и стабильное репо, и вы исправляете исправления ошибок из стабильного, я бы просто упомянул, что в слиянии: "сливается со стабильным". Эти слияния, как правило, больше, поэтому они помогают объяснить их людям, которые приходят позже.