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

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

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

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

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

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

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

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

Ответы

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

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

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

Ответ 4

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