it-roy-ru.com

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

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

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

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

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

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

237
Anthony Compton

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

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

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

152
Artefact2

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

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

git branch -d branch_name

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

git Push Origin --delete branch_name

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

git Push Origin :branch_name

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

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

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

45
Adam Dymitruk

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

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

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

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

28
chesterbr

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

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

Обычные методы удаления веток git уже были описаны выше, и они работают как положено. У git нет одной или двух команд Word, что означает: «Эй, git, удалите как локальную, так и удаленную ветку». Но это поведение можно имитировать с помощью сценария Shell. Например, возьмите скрипт оболочки Зака ​​Холмана '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. Короче говоря, вы не потеряете историю от простого слияния. 

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

3
jfmercer

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

1
Michael Fürstenberg

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

git remote Prune Origin
0
tkruse

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

git fetch --Prune
0
Thomas Kettenbach