Какой хороший процесс для управления постоянными кодами в git? - PullRequest
2 голосов
/ 18 января 2012

Я поддерживаю три строки кода для каждого проекта: «мастер» для последней разработки, «тест» для стабилизации и «prod» для оперативного кода, а также любые ветви функций.

Периодически я хочу отражать все изменения из одной ветви в другую. Конечно, подталкиваю мастера в тест, чтобы начать стабилизацию для нового релиза. Или протолкнуть тест в prod, чтобы сделать стабильную версию живой. Но также, чтобы принести исправления из теста в мастер или даже иногда из prod в тест (в случае срочного исправления). Есть также некоторые специфичные для отрасли изменения, такие как URL-адреса и ключи. Git замечательный, и я не могу себе представить, сколько времени он спас меня от других систем. Но я не уверен, как это сделать, не сталкиваясь с неприятностями время от времени.

Удаление и воссоздание этих трех «первичных» ветвей нецелесообразно, поскольку они поддерживают облачные среды, а также потому, что мы распространили разработчиков. Точно так же перебазирование проблематично, потому что каждая из ветвей является общей, и изменения выталкиваются из каждой из них. Я объединялся в обоих направлениях, как и с другими системами контроля версий, такими как Perforce: объединение исправлений из теста в мастер, а затем новая разработка из мастера в тест. Но это вызвало серьезные проблемы, которые я не до конца понимаю.

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

Заранее спасибо за ваши мысли!

1 Ответ

2 голосов
/ 18 января 2012

Мне никогда не приходилось сталкиваться с таким «фиксированным соглашением об именах», хорошо работающим для ветки интеграции и ветки prod, особенно после первого выпуска в производство.

Я всегда склонен называть эти две ветви после текущей версииЯ строю (test_1.0 и prod_1.0, или test_2.3 и prod_2.3 и т. Д.).
Это ограничит область слияний (поскольку они явно предназначены для конкретного выпуска, и яя уверен, что в этих ветках нет какой-то разработки, смешанной по ошибке из другого выпуска).

Если вы хотите иметь только одну ветку 'dev' (* в вашем случае), выОбязательно сбрасывайте указанную ветку master в начале каждого нового выпуска.
A merge --theirs из prod_x.y в master может помочь, за исключением того, что merge --theirs не существует.Существует способов симулировать такое слияние, хотя .

...