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

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

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

git branch -d branch_name

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

git push origin --delete branch_name

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

git push origin :branch_name

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

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

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

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

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

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

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

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

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

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

git remote prune origin