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

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

Workflow:

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

Любые проблемы здесь?

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

Merging with or without fast-forwards

Это взято из успешной Git ветвящейся модели от Vincent Driessen, очень приятного рабочего процесса для использования с Git, который я применяю для большинства моих проектов.

Ответ 3

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

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

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

Ответ 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

Ответ 5

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

ИЗМЕНИТЬ Поэтому, вместо слияния, по крайней мере, для короткоживущих ветвей, я думаю, что идея состоит в том, чтобы переложить их на мастера. то вы попадаете в линейную историю изменений, и вся ветвь становится частью основного ствола. в этом случае у вас есть все изменения, поэтому вам явно не нужна копия.