Исправление ошибок в ветке функций

Question

Мы используем успешную модель ветвления Git от Винсента Дриссена для нашей модели ветвления. Все хорошо, но я не видел ни одной конкретной проблемы.

Из того, что я понял, когда требуется новая функция, вы ветвитесь development и создаете новую ветку feature. Вы бы поработали над этим, и когда вы закончите, вы объедините эту ветку с веткой development.

Что делать, если разработчик создает функцию, а затем объединяет эту функцию с development, только чтобы узнать, что в коде функции есть некоторые ошибки. Где это должно быть исправлено? Должна ли новая ветка fix / bugfix быть запущена из разработки, и там должен быть исправлен код? Я не вижу другого пути.

Как можно поступить об этом?

Спасибо

Answer 1

Помните, что модель - это просто модель - она ​​дает вам структуру, которая делает вас более эффективными, а не слепо следуя набору правил.Это означает, что вы можете свободно настраивать и выяснять, что работает в вашей ситуации, потому что это может не сработать в каждой ситуации.

Я думаю, у вас есть выбор в этой ситуации:

1. Откатите слияние и продолжите работу над веткой объектов до тех пор, пока она не будет готова
2. Запустите новую ветку, чтобы исправить ошибку.

Выбор того, что вы выберете, зависит от таких факторов, как:

• Могут ли ваши клиенты увидеть ошибку?Сделайте исправление или ветку исправлений.
• Является ли ошибка действительно плохой и остановит другой прогресс в ветви разработки?Откатите изменения.
• Это незначительная проблема с минимальным внешним воздействием?Просто продолжите работу над веткой возможностей и снова объединитесь, когда будете готовы.

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

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

Грубое визуальное представление вашего выбора:

Answer 2

Как насчет нахождения коммита, который привел к ошибке, и создания новой ветки с корнем там ?При таком подходе:

• Нет риска создания неработающих ссылок из-за операций перебазировки
• Только из предков ветви разработки, ветви компонентов и любой другой ветви, которая может бытьзатронут, вы можете сказать, где вы должны объединить свою ветку исправления ошибок, как только это будет сделано.Это верно даже в том случае, если «функция» сливалась с «разработкой» несколько раз с момента появления ошибки.
• Если вы определите коммит, который привел к ошибке, и root оттуда, разработчики смогут сказатьгде им нужно объединить ветку с исправлениями ошибок, даже если они не знакомы с макетом репо
• У вас будет ветвь, которую вы можете объединить, не боясь ввязать несвязанные последующие изменения.Например - скажем, кто-то работает над «Feature-beta», которая является подразделом «Feature», которая разошлась вскоре после появления ошибки.Они могут легко извлекать ветку с исправлениями ошибок, не беспокоясь о том, что нужно добавить и все остальное, что произошло с «фичей».
• Этот подход уменьшает необходимость выбора типа "вишня", что имеет недостаток в том, что он меняет имякоммитов (таким образом подрывая одно из огромных преимуществ git, которое заключается в применении однозначного имени ко всему.)

Answer 3

Если эта функциональная ветвь является общедоступной (т. Е. Передается в удаленное хранилище, которое клонируется / используется другими), лучше создать новую ветвь и изолировать отладку в указанной ветви исправлений.
(вместопытается перебазировать ветку 'feature' поверх ветки 'develop').

Идея состоит не в том, чтобы записывать промежуточные коммиты отладки непосредственно в ветку develop, а в том, чтобы записывать только результирующий коммит, которыйисправит ошибку, возникшую в результате feature слияния веток.

Answer 4

Просто создайте ветку (или используйте старую объединенную feature ветку) и исправьте ее там.

Использовать старую ветку / создать новую ветвь точно так же - вы не можете назвать, что после слияния.