Как мне управлять несколькими ветками разработки в Git?

Question

У меня есть 5 ветвей одной системы - назовем их мастер, Лондон, Бирмингем, Манчестер и демо. Они отличаются только файлом конфигурации, и у каждого есть свой набор графических файлов.

Когда я занимаюсь разработкой, я создаю временную ветку из master, вызываемую после функции, и работаю над этим. Когда все будет готово к слиянию, я извлекаю мастер и включаю git merge, чтобы внести свою работу. Это, кажется, работает просто отлично.

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

Когда ветка наконец-то верна, я отправляю ее в депо и перетаскиваю каждую ветку в коробку Linux для окончательного тестирования. Оттуда выпуск в производство использует rsync (для игнорирования самого репозитория .git) , Эта фаза работает просто отлично.

Я единственный разработчик на данный момент, но мне нужно получить твердый процесс, прежде чем приглашать на помощь :)

Answer 1

Могут помочь две техники:

• подмодули : если у вас есть 5 "сетевых проектов", каждый из которых состоит из:
  • общий код (который получает расширенную функцию после функции)
  • специальный код (указанные графические файлы или значения конфигурации, один набор для каждого сайта)
• файлы конфигурации шаблона

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

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

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

Answer 2

git rebase ваш друг.

Внесите изменения в основную ветку, как вы всегда это делаете.Когда вы закончите, проверьте одну из своих ветвей (скажем, Бирмингем) и выполните git rebase master.git внесет изменения, сделанные вами в master, между текущим коммитом и коммитом, на котором основан Бирмингем.Есть хорошие документы по команде на межсетевом.Вот два, которые я нашел

http://darwinweb.net/articles/86

http://www.eecs.harvard.edu/~cduan/technical/git/git-5.shtml

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

Answer 3

Другая техника:

Как только ваша новая функциональность перейдет в master, объедините мастер со всеми другими соответствующими ветвями.

Исходное состояние:

o---o-master
    \
     o-London

Новый коммит в master:

o---o---o-master
    \
     o-London

Объедините новую функциональность с лондонским филиалом с git checkout London; git merge master:

o---o---o-master
    \   \
     o---o-London

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

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

Было бы неплохо иметь возможность построить все ваши конфигурации без каких-либо проверок между ними, не так ли?