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

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

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

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

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

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

7 223
github version-control git-gui git-branch

7 ответов:

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

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

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

141

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

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

git branch -d branch_name

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

git push origin --delete branch_name

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

git push origin :branch_name

который читается как "push nothing into branch_name at origin".

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

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

44

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

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

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

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

25

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

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

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

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

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

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

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

3

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

1

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

git remote prune origin
0