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

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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

git branch -d branch_name

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

git push origin --delete branch_name

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

git push origin :branch_name

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

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

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

Ответ 3

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

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

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

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

Ответ 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

Ответ 5

Кажется, вы хотите удалить ветвь 2011_Hotfix, не теряя ее истории. Сначала я буду обсуждать удаление, а второй - второй.

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

Ответ 6

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

Ответ 7

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

git remote prune origin