Где хранить различия между dev и производственной веткой в ​​git? - PullRequest
6 голосов
/ 25 января 2012

У меня есть проект, которым я управляю из репозитория git. Мы используем стратегию ветвления progit (как описано в принятом ответе, здесь: Стратегия ветки Git для небольшой команды разработчиков ), где одна ветвь является производственной ветвью, а другая ветвь является ветвью разработки / тестирования. Мы внедряем код, используя ткань.

Когда мы будем готовы выпустить новую рабочую версию с помощью git, мы объединяем ветку разработки / тестирования с производственной ветвью, а затем развертываем производственную ветвь с использованием Fabric. Проблема заключается в том, что между разработкой и производством существуют различия в коде - некоторые логотипы меняются, другие хосты / учетные данные БД и тому подобное. Я хранил файл .patch, содержащий различия и позволяющий матрице применять патч при развертывании производственной среды, но это не так хорошо работает. В частности, он полностью потерпит неудачу, если какой-то код вокруг патча изменился - патч не может быть применен, и мое развертывание прерывается.

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

Один конкретный случай использования, который меня беспокоит, - это необходимость исправления. В настоящее время мы делаем это путем отделения от производственной среды, внесения изменений и последующего слияния этой ветви с разработкой и производством. Если производственная ветвь отличается от разработки, могут ли эти изменения быть перенесены в ветку разработки, когда исправление объединено с разработкой?

Ответы [ 2 ]

9 голосов
/ 25 января 2012

Ваш вопрос в основном сводится к тому, «как я могу внести изменения в одну ветку, а затем, чтобы это изменение не распространялось, когда я сливаюсь в другую?».Это достаточно просто.На данный момент я предполагаю, что ваша производственная ветвь в основном представляет собой серию слияний, либо из ветви dev, либо из ветви исправлений.Так что, предположительно, git merge production из вашей ветки разработки не внесет никаких изменений.Учитывая это, продолжайте вносить изменения в производственную ветку.Теперь передайте их.Теперь загляните в ветку разработки и запустите git merge -s ours production.Это в основном означает «слияние с производством, но отклонение всех их изменений».Это создаст коммит слияния, но на самом деле не затронет вашу ветку разработки.

После того, как это слияние выполнено, вы можете теперь без беспокойства объединить вашу производственную ветку с разработкой (или, скорее, слить ветки исправлений), потому чтотеперь ваш производственный коммит уже «слился» с разработкой (несмотря на то, что изменения кода были отклонены).Поэтому объединение ветвей исправлений не приведет к использованию только производственного кода.

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

0 голосов
/ 20 января 2015

У меня также есть этот запрос в ветке разработки и производственной ветке.Я не думаю, что git merge -s ours ** - хорошее решение, потому что оно может просто гарантировать, что последующее слияние не будет перезаписано, а после этого оно вызовет родительское отношение между dev и production.Вы должны использовать git merge -s our ** каждый раз, и это сделает граф журнала действительно уродливым и бессмысленным.

Поэтому я рекомендую использовать

git cherry-pick

.Это гарантирует содержание, которое вы хотите получить.

...