Что делать с экспериментальными неслитыми ветками git?

Question

Каковы текущие лучшие практики с ветками git, которые были созданы для тестирования решения ошибки и не были объединены, потому что процесс проверки показывает, что они ошибочны или есть лучшие решения проблемы?

Пример. В проекте fizzbuzz есть отчет об ошибках, сообщающий о сбое в пустых полях.

• Я создаю новую ветку handle-empty-fields и делаю два коммита в эту ветку, «решая» проблему.
• Затем я отправляю эту ветку менеджеру проекта fizzbuzz, связывая его в отчете об ошибке.
• Кто-то находит ошибку в моем исправлении, пишет другой патч, и этот патч принят.

Теперь код в handle-empty-fields моем коде бесполезен: он неправильный и больше не может быть применен к коду, но на него есть ссылка в этом отчете об ошибке.

Что мне делать? Сохранить ветку? Я быстро получу десятки заброшенных веток, а у git нет возможности пометить ветку как заброшенную или закрытую. Удалить ветку? Но тогда люди, просматривающие этот отчет об ошибке, найдут его и получат 404.

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

Обновление : похоже, github никогда не удаляет коммиты, содержащиеся в запросах на получение. Таким образом, если вы отправите свои изменения и превратите их в запрос на извлечение, вы сможете позже удалить ветку, не потеряв ни одного из ваших изменений. Ну, пока GitHub еще работает;).

Answer 1

То, как я это делаю, это присвоить ему тег. Используйте полный тег и дайте ему описательное имя. Затем вы можете удалить ветку, чтобы она не отображалась в ваших списках веток, но поскольку она помечена, ветку все еще можно воссоздать, проверив ветку. Все коммиты в теге будут по-прежнему доступны, и вы не потеряете коммитов в git gc Что-то вроде этого, возможно:

git tag -a partialBugfixXXX -m"Tagging a branch that went into fixing bug XXX"

Answer 2

git update-ref refs/Attic/handle-empty-fields refs/heads/handle-empty-fields

В качестве альтернативы сохранению мертвых ветвей в тегах вы можете использовать отдельное пространство имен refs.Плюс в том, что список тегов остается незагроможденным.Недостатком является переход от фарфора к уровню сантехники в мерзавце.

Answer 3

Я думаю, это будет зависеть от конкретных обстоятельств.Возможные решения:

• Добавить комментарий к сообщению об ошибке, указывая, что упомянутая ветка оказалась бесполезной и была удалена.Если вы чувствуете, что ветка имеет какое-то значение, кратко опишите, что вы сделали.Таким образом, люди получают необходимую информацию, даже если ветка исчезла.

• Сохраните ветку, но каким-то образом переименуйте ее, чтобы пометить как «заброшенную».Добавьте комментарий к сообщению об ошибке, чтобы указать это (и измените ссылку на ветку).Например, у вас может быть какое-то соглашение, например, добавление префикса "OLD-" к именам ветвей.

• Пометьте ветку, затем удалите ее (и снова упомяните об этом в записи базы данных об ошибках).Таким образом, ветка может быть удалена, но коммиты по-прежнему доступны через тег.Обратите внимание, что git предлагает простые пространства имен для тегов (и ветвей) - вы можете включить в имя символ '/'.Вы можете просто договориться о соглашении, например, использовать теги в "oldbranch /".( Адаптировано из ответа Абизерна. )

• После того, как ветвь была объединена, вы можете просто упомянуть / связать коммит слияния в отчете об ошибке.Тогда ветвь, вероятно, менее интересна, поскольку она содержится в коммите слияния.

Как правило, вы можете принять специальное соглашение об именах для исправлений ветвей.

В моем (личном) репозитории git для каждой найденной ошибки я сначала открываю ошибку в базе данных ошибок.Если я затем работаю над этим, я создаю ветку, имя которой заканчивается идентификатором ошибки (например, «opencrash-342», «handle_empty_file-663»).Таким образом, связь между базой ошибок и ветвями очевидна.

Кроме того, если список ветвей становится слишком длинным, вы всегда можете выполнить фильтрацию по добавленному идентификатору (например, составить список закрытых ошибок и небольшой скрипт).отфильтровать их из вывода «git log» и т. д.).

Answer 4

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