Нет ни реальной стоимости, ни реальной выгоды.
Помните, что названия филиалов в значительной степени эфемерны , и в любом случае, безусловно, развиваются с течением времени.Если вы будете хранить оба имени в течение длительного времени - имя с именем master, которое вы, вероятно, сохраните, - то через некоторое время в будущем вы увидите такой шаблон коммитов:
(time increasing towards the right)
o--o---------M-----N <-- master
\ / /
o--o--o--o--o <-- dev
дляпервый случай, когда вы git merge --no-ff dev в master создаете слияние M через некоторое время T, а затем git merge снова, чтобы создать слияние N через некоторое время.
(OP отмечает, что этот первый шаблон может быть чем-то желательным в ветке релиза, например, с именем production, где имя в нижней строке равно master.)
Если выпозвольте dev воссоединиться master на M, вместо этого вы получите:
o--o---------M------N <-- master
\ / \ /
o--o--o o--o <-- dev
Это лучше?Это хуже?Вас это волнует?
Если вы заберете имя dev и вместо этого будете использовать feature имена, вы можете увидеть:
o--o---------M------N <-- master
\ / \ /
o--o--o o--o
, где первыйПузырь вдоль нижнего ряда был временным именем feature/foo, а второй пузырь был временным именем feature/zorg.
Опять же, реальный вопрос будет: вас это волнует?Единственное, что здесь постоянно, - это сами коммиты.Сделайте сообщения коммита хорошими - стандартные merge ... сообщения являются ужасными, но по крайней мере что-то вроде:
merge branch feature/foo
и:
merge branch feature/zorg
предложение некоторые ключ к пониманию того, что это было.Сравните с:
merge branch dev
, который вообще ничего вам не говорит, независимо от того, какой рисунок строчки вы наблюдаете в коммитах.