Git ветки функций и незначительные улучшения кода

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

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

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

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

Мы имеем следующие идеи:

1) cherry - выберите изменения из ветки 'refactorX' в нашу ветку функций. Продолжайте разрабатывать и позволять git (надеюсь) выяснить, когда мы сможем вернуться к разработке, что оно уже имеет изменение от ветки рефакторинга.

2) Слейте ветвь 'refactorX' в нашу ветку функций и продолжите разработку. (примечание: разветвление ветки для "refactorX", возможно, было позже в истории разработки, поэтому мы считаем, что это может иметь проблемы)

3) Еще один более умный вариант, который мы еще не знаем.:)

То, что мы ищем, - это руководство по наилучшей практике в отношении обработки этой части рабочего процесса. Говоря об этом, мы знаем, что это будет часто возникать, и мы хотим найти гладкий и эффективный способ справиться с этим в нашем рабочем процессе.

Любые рекомендации?

Ответ 1

Похоже, вы пытаетесь избежать объединения ветки разработки обратно в ветвь функции. Полезно избегать этого шага, но иногда это необходимо, особенно в таких ситуациях.

Метод, который мы также начинаем использовать, составляет git rebase --onto. Вместо объединения ветки разработки в ветвь признака ветвь признака может быть перенесена в конец ветки разработки, чтобы получить новые функции.

Когда вы используете центральный репозиторий, вероятно, наиболее полезно создать новое название ветки. Например, мы добавляем -v2 в новое имя ветки.

Типичный процесс перемещения может выглядеть как

git checkout feature
git branch -m feature-v2
git rebase --onto develop develop
git push -u origin feature-v2

Теперь у вас есть новый код в ветки вашей функции, но он не объединил ветвь разработки в ветки функции.

Ответ 2

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

В ASCII-стиле перед рассмотрением рефакторинга:

--- development
               \
                --- refactoring
                               \
                                --- feature1
                                --- feature2

И потом:

------ development|refactoring
                              \
                               --- feature1
                               --- feature2

Затем, если вы закончите feature1 и слейте его в:

------ refactoring --- development|feature1
                  \
                   --- feature2

Вы снова добавите функцию2 в разработку:

------ refactoring --- development|feature1
                                           \
                                            --- feature2

И тогда вы можете объединить функцию2 как обычно:

------ refactoring --- feature1 --- development|feature2