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

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

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

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

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

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

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

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

22
задан gioele 31 January 2012 в 23:11
поделиться