Когда удалять ветки в Git?

Question

Предположим, у нас есть стабильное приложение.

Завтра кто-то сообщит о большой старой ошибке, которую мы решили исправить сразу. Поэтому мы создаем ветку для этого исправления из «master», называем его «2011_Hotfix» и добавляем его, чтобы все разработчики могли совместно исправлять его.

Мы исправляем ошибку и объединяем «2011_Hotfix» с «master» и текущей веткой разработки. И нажать «мастер».

Что нам теперь делать с "2011_Hotfix"? Должно ли оно оставаться вечным до конца времени как ветвь, или теперь мы должны удалить его, так как оно служит своей цели? Кажется нечистым просто оставлять ветки повсюду, так как список ветвей, вероятно, станет очень длинным, большинство из которых больше не нужны.

В случае его удаления, что будет с его историей? Будет ли это поддерживаться, даже если фактическая ветвь больше не доступна? Кроме того, как бы я удалил удаленную ветку?

Answer 1

Вы можете безопасно удалить ветку с помощью git branch -d yourbranch.Если он содержит неоплаченные изменения (т. Е. Вы потеряете коммиты, удалив ветку), git сообщит вам об этом и не удалит.

Итак, удаление объединенной ветки дешево и не заставит вас проигратьлюбая история.

Чтобы удалить удаленную ветку, используйте git push origin :mybranch, предполагая, что ваше удаленное имя является источником, а удаленная ветка, которую вы хотите удалить, называется mybranch.

Answer 2

Что вам нужно сделать, это пометить все, что вы выпускаете.Держите ветки вокруг, когда вы активно развиваетесь.

Удалить старые ветви с помощью

git branch -d branch_name

Удалить их с сервера с помощью

git push origin --delete branch_name

или старого синтаксиса

git push origin :branch_name

, который читается как"ничего не вставлять в имя_в ветви в начале".

Тем не менее, до тех пор, пока DAG (ориентированный ациклический граф) может указывать на него, коммиты будут в истории.-flow ", и это может дать более глубокое понимание управления выпусками, ветвления и тегов.

Answer 3

Поскольку в вопросе есть тег "github", я бы также добавил это: в частности, в Github , если вы вытягиваете запрос ветку, и она объединяется (либо черезпользовательский интерфейс или слияние ветви запроса извлечения), вы не потеряете данные запроса извлечения (включая комментарии), , даже если удалите ветвь .

Следствие этого:Вы включаете запросы на получение данных как часть вашего рабочего процесса (который прекрасно сочетается с обзорами кода), вы можете безопасно удалять ветви, как только они объединяются.Это настолько распространенное явление, что недавно Github добавил (приятную) функцию, которая выдает кнопку «удалить ветку» сразу после объединения запроса на извлечение.

Но стоит отметить, что каждая группа должна принять рабочий процесс, который ей подходитлучше (и это может или не может привести к удалению таких веток).Моя текущая рабочая группа, например, удаляет все ветви, которые не являются основными или не связаны с развертыванием (например, производство, подготовка и т. Д.), Как только их запросы извлечения объединяются, и у нас все еще есть полное отслеживание того, как сформировались соответствующие коммиты.каждое поэтапное улучшение каждого продукта.

Конечно, никакое управление историей (запросы на извлечение или иное) не заменяет надлежащую маркировку версий (которую вы предпочтительно автоматизируете тем же инструментом / сценарием, который развертывает / упаковывает версию), поэтому вывсегда может быстро переключиться на то, что происходит с вашими пользователями в данный момент.Пометка также является ключом к решению вашей первоначальной проблемы: если вы установили, что любая ветка, слитая с «рабочими» ветвями, может и должна быть удалена, а любая ветка с тегом версии, «производственной» и т. Д. Не должнаисправления всегда будут работать, пока они не будут интегрированы в будущую версию.

Answer 4

Я бы добавил, что недостатком удаления веток является то, что вы нарушаете любые гиперссылки на эти ветки на GitHub (этот вопрос помечен как github).Вы получите ошибку 404 Not Found для этих ссылок.Вот почему я изменяю свои ссылки, чтобы они указывали на коммит или тэг после удаления ветки на GitHub.

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

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

Сначала я удаляю свою локальную ветку.Это предотвращает случайное нажатие позже.

git branch -d branchName

Затем я удаляю ветку удаленного отслеживания

git branch -dr remoteName\branchName

Затем я удаляю ветку на GitHub.Я использую веб-интерфейс, но эквивалентная команда приведена ниже.

git push remoteName :branchName

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

git tag -a tagName commitOrBranchName

Затем я помещаю тег в github

git push remoteName tagName

Answer 5

Кажется, что вы хотите удалить ветку 2011_Hotfix, не теряя ее историю.Я буду обсуждать удаление первого и историю второго.

Обычные git методы удаления веток уже были описаны выше и работают как положено.git не имеет команды из одного или двух слов, которая означает: «Привет, git, удалите как локальную, так и удаленную ветку».Но это поведение можно имитировать с помощью сценария оболочки.Например, возьмите скрипт оболочки Зака ​​Холмана 'git-nuke' .Это очень просто:

#!/bin/sh
git branch -D $1
git push origin :$1

Поместите это в исполняемый файл (например, git-nuke) в один из ваших каталогов $PATH.Если вы не в ветке 2011_Hotfix, вы просто запустите git-nuke 2011_Hotfix, чтобы удалить как локальную, так и удаленную ветки.Это намного быстрее и проще - хотя, возможно, более опасно - чем стандартные команды git.

Ваша забота о сохранении истории хороша.В этом случае вам не нужно беспокоиться.После слияния 2011_Hotfix с master все коммиты с 2011_Hotfix будут добавлены в историю коммитов master.Короче говоря, вы не потеряете историю от простого слияния.

У меня есть еще одно слово, которое, возможно, выходит за рамки вашего вопроса, но, тем не менее, уместно.Давайте представим, что есть 20 крошечных «незавершенных» коммитов на 2011_Hotfix;однако вы хотите, чтобы в историю master была добавлена ​​только одна полная фиксация 2011_Hotfix.Как объединить все 20 маленьких коммитов в один большой коммит?К счастью, git позволяет объединить несколько коммитов в один коммит, используя git-rebase.Я не буду объяснять здесь, как это работает;хотя, если вам интересно, документация для git-rebase превосходна.Обратите внимание, что git rebase переписывает историю, поэтому ее следует использовать разумно, особенно если вы новичок в ней.Наконец, ваш сценарий 2011_Hotfix касается команды разработчиков, а не индивидуальных разработчиков.Если члены проектной команды используют git rebase, для группы было бы разумно иметь четкие рекомендации по использованию git rebase, чтобы некоторые разработчики-ковбои в команде невольно не повредили историю проекта git.

Answer 6

Если он был успешно объединен и, возможно, даже помечен, я бы сказал, что он больше не нужен.Так что можете смело делать git branch -d branchname.

Answer 7

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

git fetch --prune

Answer 8

Вы можете удалять ветки во всех основных веб-интерфейсах, таких как github, BitBucket.После удаления ветки онлайн вы можете удалить локальную ветку, используя

git remote prune origin