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

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

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

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

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

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

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

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

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

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

Удалить старые ветви с

git branch -d branch_name

Удалить их с сервера с

git push origin --delete branch_name

или старый синтаксис

git push origin :branch_name

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

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

Google "git-flow", и это может дать более глубокое понимание управления выпусками, ветвлениями и тегами.

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

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

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

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

Я бы добавил, что недостатком удаления веток является то, что вы нарушаете любые гиперссылки на эти ветки на 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

Кажется, вы хотите удалить 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«s история коммитов. Короче говоря, вы не потеряете историю от простого слияния.

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

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

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

git fetch --prune

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

git remote prune origin