Как слить готовый рабочий патч вместо всей его истории в тестовую ветку?

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

test — это место, где ветви функций объединяются после того, как они были проверены другим разработчиком, staging — это ветвь, где ветви функций объединяются после того, как они прошли экспертную оценку, TT и UAT.

Следующий разработчик начинает работать над следующей картой и создает такую ​​ветку:

git checkout test
git checkout -b story/bar

Разработчик заканчивает работу и передает ее на экспертную оценку. Рецензент доволен кодом и переходит в TT и UAT, все довольны, и он переходит на PO. P.O доволен, а затем объединяет функциональную ветку с staging

git checkout staging
git merge origin/story/bar

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

  • Что-то не так с нашим подходом и какие-либо предложения по его улучшению?
  • Должны ли мы создавать наши функциональные ветки вне промежуточной стадии?

git branching-and-merging branching-strategy
person Filype    schedule 27.03.2013    source источник
comment
Да, если вы хотите просмотреть исправления отдельно от других, вы должны создать (и объединить обратно) ветки, которые включают только их (а не несвязанные вещи).   -  person Thilo    schedule 27.03.2013

Ответы (1)


arrow_upward
1
arrow_downward

По сути, вам нужно учитывать рабочий процесс публикации (push/pull), а не только рабочий процесс слияния (от feature до test до staging до...): этот рабочий процесс публикации ортогонален объединить рабочий процесс.

Любая новая ветка feature должна разрабатываться поверх САМОЙ ПОСЛЕДНЕЙ официальной версии, с которой вы хотите использовать эту feature.

Если это staging, это означает:

git fetch
git checkout -b newFeature origin/staging
# hack...

# make sure newFeature still works on top of staging as right now
# since staging might have received other feature 
# during the development of newFeature

git fetch
git rebase origin/staging
# local and/or unit tests...
# push for review
git push -u origin newFeature

Когда вы объединяете feature с test или staging, вы должны перебазировать newFeature поверх test, затем поверх staging и только затем объединить newFeature (быстрое слияние вперед).
Любой конфликт во время перебазирования означает, что функция отклонена. (разработчик должен получить, а затем локально перебазировать эту ветку newFeature поверх того, что вызывает проблемы, чтобы увидеть, почему возникает конфликт).

person VonC    schedule 27.03.2013
comment
Спасибо за отзыв. После прочтения ссылок, которые вы разместили, я начинаю видеть потребность в ветке-кандидате на выпуск, а не в промежуточной стадии, тогда мы можем создавать ветки функций из ветки-кандидата на выпуск вместо тестовой. - person Filype; 27.03.2013
comment
@Filype правда, какая-то официальная ветка, которую все разработчики могут использовать в качестве справки. Но части rebase тоже важны. - person VonC; 27.03.2013