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

Я не хочу заканчивать с 82 функция ветви висит вокруг, поэтому мне интересно, какие потенциальные недостатки заключаются в простом удалении ветви функции, как только я объединю ее с master.

документооборот:

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

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

5 71
github version-control branch

5 ответов:

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

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

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

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

49

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

Merging with or without fast-forwards

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

81

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

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

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

6

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

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

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

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

1