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

Question

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

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

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

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

У нас есть следующие идеи:

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

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

3) Какой-то другой умный вариант, о котором мы пока не знаем. :)

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

Есть рекомендации?

Answer 1

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

В искусстве ASCII до проверки рефакторинга:

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

И после этого:

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

Затем, если вы закончите Feature1 и объедините его в:

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

Вы перебазируете Feature2 в разработку снова:

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

И тогда вы можете объединить feature2 в обычном режиме:

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

Answer 2

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

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

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

Типичный процесс перемещения может выглядеть следующим образом:

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

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