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

88

Я не хочу, чтобы вокруг висело 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 version-control branch Bstpierre
источник
1
Я бы сказал, что никаких проблем, потому что, если они вам действительно нужны, вы всегда можете воскресить удаленную ветку позже.
Slebetman 02
@slebetman Насколько мне известно, удаленную ветку воскресить невозможно. Однако, если ветка была полностью объединена с мастером перед ее удалением, в этой ветке больше не должно быть необходимости.
Симеон
1
@Simeon Да, ты можешь. Git никогда не удаляет коммиты, поэтому, когда вы удаляете свою ветку, вы просто удаляете ее имя. Чтобы воскресить удаленную ветку, вам просто нужно запомнить последнее, что вы сделали для этой ветки, и вы можете найти git reflogее. Тогда
проверьте
@slebetman, это будет верно только в том случае, если ветка в конечном итоге была объединена. если коммиты останутся позади, они в конечном итоге станут недоступными и через определенное время будут подвергнуты сборке мусора. даже записи в рефлоге со временем будут удалены, по умолчанию у вас есть около 90 дней.
Goldenratio 01
@goldenratio: Есть ссылки на это?
slebetman 01

Ответы:

61

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

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

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

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

каменщик
источник
1
Проверка тега устанавливает HEAD, но не создает автоматически ветвь. HEAD в фиксации без ветки - вот что делает его отсоединенным.
Binarian
1
Вы правы, он устанавливает HEAD на идентификатор фиксации, а не на ссылку. Эта часть моего OP неверна. Я должен его обновить.
masonk
96

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

Слияние с перемоткой вперед или без нее

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

lkraider
источник
Это еще один хороший способ сохранить историю, потому что вы можете выбрать коммиты, которые доступны из функции, но не из мастера: rev ^ 1..rev ^ 2. Обратной стороной является то, что он мешает любому перемещению, которое вы, возможно, захотите сделать из своей основной ветки (например, если вы хотите, чтобы мастер перебазировался на исходящий удаленный, что очень часто).
masonk 03
1
У меня не было этой проблемы. Наша команда синхронизируется через github, и мне обычно не нужно перебазировать, но я не думаю, что это недостаток. Даже если вы перебазируете свою ветку разработки и функции, ветвление останется видимым на графике, и важно то, что находится в ветке функции относительно разработки, а не фиксация, из которой вы изначально удалились при создании этой ветки.
lkraider 03
@Ikraider, спасибо за напоминание. Я видел эту статью, когда впервые изучал git, теперь она имеет для меня больше смысла. Я переустанавливаю свои функциональные ветки, но merge --no-ffвозвращаюсь к мастеру, потому что, как вы говорите, вы можете видеть историю.
bstpierre
7

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

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

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

Карл Билефельдт
источник
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
Физер Хан
источник
1

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

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

второй
источник
Так что нет никакого смысла держать ветку под рукой, верно?
bstpierre 02
1
Я настоятельно рекомендую избегать "перебазирования". Ребазинг обычно вреден, но полезен только в некоторых случаях.
Дитрих Эпп
9
Ребазинг - это вполне разумный рабочий процесс для ваших местных частных филиалов. Очень часто синхронизация с восходящей работой выполняется, например, путем перебазирования («перебазирования вниз »). Гораздо реже и обычно вредно восстанавливать *. Второй ответ на самом деле не имеет смысла, потому что независимо от того, выполняете ли вы ребазинг или объединяете восходящие изменения, вам все равно нужно как-то подтолкнуть этот материал "вверх". Даже в вашем локальном филиале вам в какой-то момент придется объединить свои функции, чтобы освоить их. Преимущество перебазирования ваших функций в том, что это слияние ускоряется.
masonk 03
1
Тем не менее, есть кое-что, на что следует обратить внимание при перебазировании веток, что меня недавно укусило. Сейчас это очевидно, но я месяцами ходил на долгоживущую ветку, всегда переустанавливая все на master. В итоге получилось около 600 хороших, детализированных коммитов, но мастер претерпел дико рефакторинг и полностью менял много раз. Перебазируя всю ветку каждый раз, я вырезал ее старые коммиты из их соединения с главными коммитами, которые имели для них смысл. Теперь я предпочитаю объединять в мастере, когда это необходимо. Перебазирую только в том случае, если это никак не повлияет на историю ветки.
Гэри Фикслер