Как лучше настроить GIT для ведения продукта для нескольких заказчиков?
Пытаюсь навести порядок в нашем продукте, написанном на c++. Сейчас у нас весь код в одной ветке, перед отгрузкой выделяем отдельную ветку. Фиксы до отгрузки исправляем в ветке релиза.
Этим продуктом пользуется 10 заказчиков, с которыми давно ведется работа. Так исторически сложилось, что проект большой, отгружался разным заказчикам в разное время. Для каждого приходилось что-то допиливать и эти доработки "включаются в сборку" по define :( Да, я знаю что это криво.
Сейчас такие наблюдаются проблемы:
1. Так как весь код всех заказчиков в одной ветке, то клиент, получая новую версию получает ее со всеми доработками, которые ему не нужны и могут у него не работать.
2. Исправления конфликтуют с другими заказчиками.
Где можно посмотреть решение этой типовой, на мой взгляд проблемы, ведения проекта в GIT?
Что мешает иметь отдельные ветки/репозитории для каждого заказчика и делать merge/rebase относительно общей основы когда нужно? Это решает обе ваши проблемы.
Спасибо за ответ.
1. Предполагаю, что будет сложно делать перенос общего функционала по 9 репозиториям.
2. Заказчики не очень часто хотят доработок, поэтому разница между его версией и head версией всего продукта будет очень проблематично смержить
3. По сути, нам нужно вести работу над 10 проектами, часто повторяя одно и тоже, разбираться с тем, относится ли выявленный баг к заказчику или ко всему продукту.
Сложно не будет, поскольку у вас общая база и мерджить нужно будет только то, что вступает в прямой конфликт + не разруливается автоматически.
Скорее я бы даже не мерджил, а делал rebase.
То есть для каждого заказчика будет свой набор патчей поверх ванильной версии, все дистрибутивы Linux имеют пачки патчей поверх ванильного ядра, и ничего, живут как-то:) К стати, с многим ПО в дистрибутивах ситуация обстоит так же.
Если конфликтов не обнаруживается - rebase происходит полностью автоматически. Если же есть конфликт - вы пошагово можете в интерактивном режиме обновить свои патчи соответственно новой версии основы.
sandrey-80: Не знаю:) Я просто смотрю изменения пакетов и вижу как они пользуются.
К примеру, на Ubuntu 16.04 сегодня прилетело обновление systemd:
systemd (228-3ubuntu1) xenial; urgency=medium
* Merge with Debian unstable. Remaining Ubuntu changes:
- Hack to support system-image read-only /etc, and modify files in
/etc/writable/ instead.
- Simpler udev maintainer scripts (all platforms must support udev, no
debconf).
- Provide shutdown fallback for upstart. (LP: #1370329)
- Add Get-RTC-is-in-local-time-setting-from-etc-default-rc.patch: In
Ubuntu we currently keep the setting whether the RTC is in local or UTC
time in /etc/default/rcS "UTC=yes|no", instead of /etc/adjtime.
(LP: #1377258)
- Put session scopes into all cgroup controllers. This makes unprivileged
user LXC containers work under systemd. (LP: #1346734)
- Change systemd-sysv's conflicts to upstart-sysv. (LP: #1422681)
- Build using libseccomp on powerpc and ppc64el (See Debian #800818).
Upgrade fixes, keep until 16.04 LTS release:
- systemd Conflicts/Replaces/Provides systemd-services.
- Remove obsolete systemd-logind upstart job.
- Clean up obsolete /etc/udev/rules.d/README.
- systemd.postinst: Migrate mountall specific fstab options to standard
util-linux "nofail" option.
- systemctl: Don't forward telinit u to upstart. This works around
upstart's Restart() always reexec'ing /sbin/init on Restart(), even if
that changes to point to systemd during the upgrade. This avoids running
systemd during a dist-upgrade. (LP: #1430479)
- Break lvm (<< 2.02.133-1ubuntu1) and remove our dummy /etc/init.d/lvm2
on upgrades, as it's shipped by lvm2 now.
- Make udev break on mdadm << 3.3-2ubuntu3, as udev's init script dropped
the "Provides: raid-mdadm". This needs to be kept until after 16.04 LTS.
Видно что есть версия systemd в Debian, которая содержит определённые патчи поверх ванильной + версия в Ubuntu, которая основывается на версии из Debian и содержит ряд дополнительных патчей.
