Я не хочу, чтобы вокруг висело 82 функциональных ветки , поэтому мне интересно, каковы потенциальные недостатки простого удаления функциональной ветки, как только я объединю ее с мастером.
Рабочий процесс:
git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz
Есть проблемы здесь?
git reflogее. Тогда
Ответы:
Удалить после слияния - обычный способ. Вот почему git branch -d yourbranchnameперед удалением необходимо убедиться, что ветка полностью слита.
Есть несколько причин, по которым я могу придумать, чтобы сохранить ветку: вы можете оставить ее на тот случай, если у вас появятся ошибки, которые вернутся, как только она попадет в производство, или вам может потребоваться историческая запись.
В любом случае у вас есть возможность пометить заголовок ветви перед ее удалением. Тег похож на ветку, поскольку он является указателем на фиксацию, за исключением нескольких незначительных отличий: 1) фарфор обычно не отображает теги в исследовательских командах, таких как git show-branch или tab-auto complete при оформлении заказа, 2) проверка одного из них помещает вас в отдельную (не относящуюся к ссылке) HEAD 3) вы можете оставить « сообщение с тегами », в результате чего тег будет сохранен как объект в хранилище объектов, как фиксация.
Таким образом вы сохраняете историю, и если вам когда-нибудь понадобится исправить ошибку, я рекомендую просто создать новую ветку от мастера для исправления.
Я удаляю после слияния, но всегда делаю это git merge --no-ff, чтобы избежать быстрой перемотки вперед, чтобы история ветвей была видна на графике. Мне нравится знать историю того, где функциональная ветка отошла от ветки разработки и где она снова присоединилась:
Это взято из «Успешной модели ветвления Git » Винсента Дриссена, очень удобного рабочего процесса для использования с git, который я применяю для большинства своих проектов.
merge --no-ffвозвращаюсь к мастеру, потому что, как вы говорите, вы можете видеть историю.
Я могу придумать две причины, по которым вам может понадобиться некоторое время оставить функциональную ветку:
На практике в большинстве случаев удаление после слияния - это нормально.
Типичный рабочий процесс будет
// Create new branch
$ git checkout -b myfeature
// and then do some changes and commit them
// Switch to master branch
$ git checkout master
// Merge myfeature to master. --no-ff will always keep branch information.
$ git merge --no-ff myfeature
// Delete myfeature branch
$ git branch -d myfeature
// Push the changes
$ git push origin master
я думаю, что это типичный рабочий процесс (удаление после слияния)
РЕДАКТИРОВАТЬ Итак, вместо слияния, по крайней мере, для короткоживущих веток, я думаю, что идея состоит в том, чтобы перенести их на мастер. тогда вы получите линейную историю изменений, и вся ветка станет частью основного ствола. в этом случае у вас есть все изменения, поэтому вам явно не нужна копия.