Когда самое подходящее время удалить ветку git?

Question

Я не хочу, чтобы в конечном итоге 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

Есть здесь какие-нибудь проблемы?

Answer 1

Я удаляю после слияния, но всегда делаю git merge --no-ff, чтобы избежать быстрой пересылки, чтобы история ветвей была видна на графике.Мне нравится иметь историю, где ветвь компонентов отошла от ветви разработки и где она присоединилась:

Это взято из Успешная модель ветвления Git от Винсента Дриссена, очень хороший рабочий процесс для использования с git, который я применяю для большинства своих проектов.

Answer 2

Удалить после слияния обычным способом.Вот почему git branch -d проверяет, что ветвь полностью объединена, прежде чем она будет удалена.

Есть несколько причин, по которым я могу придумать, чтобы сохранить ветвь: вы можете захотеть удержать ее.в случае, если у вас появятся ошибки, когда они попадут в производство, или вам может потребоваться историческая запись.

В любом случае у вас есть возможность пометить заголовок ветви перед ее удалением.Тег похож на ветку в том смысле, что он является указателем на коммит, за исключением нескольких незначительных отличий: 1) фарфор обычно не отображает теги в поисковых командах, таких как git show-branch или tab-auto complete в checkout, 2)если вы выберете один из них, вы попадете в отдельную (не ref) HEAD 3) вы можете оставить « сообщение с тегом », в результате чего тег будет сохранен как объект в хранилище объектов, например коммит.

Таким образом, вы сохраняете историю, и если вам когда-нибудь понадобится исправить ошибку, я рекомендую просто создать новую ветку от мастера для исправления.

Answer 3

Я могу подумать о двух причинах, по которым вам может потребоваться немного сохранить ветвь функции:

• Есть вероятность, что вам ответят за дальнейшую работу.
• Другие разработчики, возможно, захотят эту функцию, не желая всего остального в master.

На практике удаление после слияния в большинстве случаев просто отлично.

Answer 4

Типичный рабочий процесс будет

 // 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

Answer 5

я думаю, что это типичный рабочий процесс (удаление после слияния)

РЕДАКТИРОВАТЬ Итак, вместо слияния, по крайней мере, для кратковременных ветвей, я думаю, что идея состоит в том, чтобы переназначить их на мастер.после этого вы получите линейную историю изменений, и вся ветвь станет частью основного ствола.в этом случае у вас есть все изменения, поэтому вам явно не нужна копия.