Как я справляюсь с несколькими ответвлениями разработки в Мерзавце?
У меня есть 5 ответвлений одной системы - давайте назовем их ведущим устройством, Лондоном, Бирмингемом, Манчестером и демонстрацией. Они отличаются только по конфигурационному файлу, и у каждого есть его собственный набор графических файлов.
Когда я делаю некоторую разработку, я создаю временное ответвление от ведущего устройства, позвонившего после функции и работы над этим. Когда готовый для слияния I ведущих устройств контроля и мерзавца объединяют функцию для введения моей работы. Это, кажется, работает просто великолепно.
Теперь я должен получить свои изменения в другие ответвления, не теряя различия между ними, которые уже являются там. Как я могу сделать это? У меня не было конца проблем с Бирмингемом, получая графику Лондона, и с конфликтами в конфигурационном файле.
Когда ответвление наконец корректно, я продвигаю его до склада и раскрываю каждое ответвление к полю Linux для заключительного тестирования, Оттуда выпуск в производство использует rsync (набор для игнорирования самого .git репозитория). Эта фаза работает просто великолепно также.
Я - единственный разработчик в данный момент, но я должен получить тело процесса перед привлекательной помощью :)
3 ответа
Два метода могут помочь:
- субмодули : если у вас есть 5 «основных проектов», каждый из которых состоит из:
- общий код (который получает расширенную функцию после функции)
- специальный код (задает графические файлы или значения конфигурации, один набор для каждого сайта)
- файлы конфигурации шаблона
Поэтому, когда вы разрабатываете новую функцию , все, что вам нужно сделать, чтобы другие сайты могли извлечь из этого пользу, - это убедиться, что их соответствующие репо ссылаются на последнее репозиторий общего кода в качестве подмодуля. Просто выполните обновление подмодуля git , и все готово.
Кроме того, с файлами конфигурации шаблонов все, что вы храните, - это значения конфигурации , а не сами файлы конфигурации (они генерируются).
Это позволяет выполнять некоторую тонкую настройку на каждом сайте, не игнорируя локальные изменения.
В заключение: вместо того, чтобы пытаться управлять всеми аспектами (общий код, файлы конфигурации, специальные файлы и т. Д.) В одном репозитории (со всеми необходимыми слияниями и ребазами), попробуйте сделайте свое приложение модульным.
Другая техника:
Как только ваша новая функциональность будет в master, слейте обратно master во все остальные соответствующие ветки.
Исходное состояние:
o---o-master
\
o-London
Новый коммит в master:
o---o---o-master
\
o-London
Слейте новую функциональность в ветку London, используя git checkout London; git merge master:
o---o---o-master
\ \
o---o-London
Заметьте, однако, что это может быть громоздко, особенно если количество веток увеличится. Я ничего не знаю о вашей системе, но если вы можете иметь все конфигурации в одной ветке, это, вероятно, будет проще (я имею в виду, чтобы все пять конфигурационных файлов и графические файлы всегда присутствовали в вашей файловой системе).
Например, с помощью makefile вы можете выбирать, какие исходные файлы компилировать и компоновать в зависимости от текущей целевой конфигурации. В вашем случае makefile может помочь вам связать графические файлы и файлы конфигурации с целевой конфигурацией.
Также было бы неплохо иметь возможность собирать все ваши конфигурации без каких-либо промежуточных проверок, не так ли?
.git rebase - ваш друг.
Внесите свои изменения в мастер-ветку, как вы всегда это делаете. Когда вы закончите, проверьте одну из других веток (скажем, Birmingham) и выполните команду
git rebase master. git притянет изменения, сделанные вами в master между текущим коммитом и коммитом, на котором основан Birmingham. В интернете есть хорошие документы по этой команде. Вот два, которые я нашел
http://darwinweb.net/articles/86
http://www.eecs.harvard.edu/~cduan/technical/git/git-5.shtml
Есть много других. Вы найдете много людей, говорящих об опасностях ребасинга. Прислушайтесь к этим опасениям, но я подозреваю, что в вашем случае преимущества значительно перевешивают риски; а знание опасностей - половина успеха.