Когда правильное время должно удалить ответвление функции мерзавца?
Я не хочу заканчивать с 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
Какие-либо проблемы здесь?
4 ответа
Удалить после слияния - это обычный способ. Вот почему git branch -d проверяет, что ветка полностью слита, прежде чем удалять.
Есть несколько причин, которые я могу назвать, чтобы сохранить ветку: вы можете захотеть придержать её на случай возвращения ошибок, когда она попадёт в продакшн, или вы можете захотеть получить историческую запись.
В любом случае, у вас есть возможность пометить головку ветки перед удалением. Метка похожа на ветку тем, что является указателем на коммит, за исключением нескольких незначительных отличий: 1) porcelain обычно не отображает теги в исследовательских командах, таких как git show-branch или tab-auto complete в checkout, 2) проверка одного из них помещает вас в отсоединённую (нерефровую) HEAD 3) вы можете оставить сообщение "tagging message", которое заставит тег быть сохранённым как объект в хранилище объектов, как и коммит.
Таким образом вы сохраняете историю, и если вам когда-нибудь понадобится исправить ошибку, я рекомендую просто создать новую ветку от master для исправления.
Я удаляю после слияния, но я всегда делаю git merge --no-ff, чтобы избежать быстрой перемотки, чтобы история ветки была видна на графике. Мне нравится иметь историю того, где функциональная ветвь отошла от ветви разработки и где она вернулась обратно:
Это взято из A successful Git branching model Винсента Дриссена, очень хороший рабочий процесс для использования с git, который я применяю для большинства своих проектов.
Я могу придумать две причины, по которым вы, возможно, захотите на некоторое время оставить функциональную ветку:
- Есть шанс, что она будет вам возвращена для дополнительной работы со стороны апстрима.
- Другие разработчики, возможно, захотят получить эту функцию, не желая, чтобы все остальное было в мастерской.
На практике в большинстве случаев удаление после слияния - это нормально.
Я думаю, что это типичный рабочий процесс (удаление после слияния)
РЕДАКТИРОВАТЬ Итак, вместо слияния, по крайней мере, для короткоживущих веток, я думаю, что идея состоит в том, чтобы перенести их на мастер. тогда вы получите линейную историю изменений, и вся ветка станет частью основного ствола. в этом случае у вас есть все изменения, поэтому вам явно не нужна копия.