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
