Эффективное резервное копирование множества версий репозитория git с использованием пространства имен ветвей.

Question

На работе мы используем Perforce для контроля версий.С этим есть проблемы:1) с помощью этой централизованной модели мы не можем регистрировать изменения, пока они не будут готовы к регрессии.Это означает, что у нас нет контроля версий в процессе разработки.2) Мы не делаем резервную копию представления клиента о депо, поэтому наша работа небезопасна, пока мы не сможем его проверить.3) У нас есть проблемы с обменом нашим кодом с каждым, если мы не попросим настроить ветку интеграции.Я пытаюсь настроить дополнительный рабочий процесс git для разработчиков, которые хотят использовать git для решения этих проблем.

Планируется использовать git-p4 для взаимодействия с сервером Perforce и создать частное репозиторий git.Это касается 1).Я планирую использовать рабочий процесс менеджера интеграции, описанный в Git Pro (http://progit.org/book/ch5-1.html), чтобы наши разработчики публиковали общедоступные репозитории, позаботившись о 3).

Наконец, мне нужно место, где разработчики смогут вносить свои изменения, чтобы их можно было использовать в ночных/внешних резервных копиях.Причина, по которой мы сейчас не делаем резервные копии представлений наших клиентов, заключается в том, что ночное архивирование представлений каждого клиента требует неэффективного использования пространства.У нас много разработчиков, и они пишут много кода.Мы не можем дублировать мнение каждого клиента.Мы хотим лишь сохранить уникальные изменения, которые они вносят только.

Я думал о том, чтобы иметь один голый репозиторий git, назовем его omni-backup, что каждый может использовать все свои ветки (и не стесняться предлагать альтернативы).Это позволит использовать эффективное хеширование sha-1 git и гарантировать резервное копирование только уникальных версий каждого файла.Хитрость в том, что все репозитории резервных копий должны быть частью одного репозитория, чтобы обеспечить эффективность использования пространства.

Проблема в том, что два человека с совершенно разными ветками выбрали для своей ветки одно и то же имя.НАПРИМЕР.У Боба есть feature филиал, и у Джейн есть feature ветка, но они предназначены для разных функций.Если Боб перейдет к омни-резервному копированию, Джейн не сможет этого сделать, поскольку это не будет быстрым слиянием.

В идеале я бы хотел, чтобы, когда Боб отправляет свою ветку функций, ветка была переименована в bob-feature на omni-backup удаленный.И когда он извлекает функцию из omni-backup, он возвращается bob-feature.

Кажется, это не так-то просто сделать в git.Похоже, я могу использовать нажимные крючки, описанные в http://www.kernel.org/pub/software/scm/git/docs/git-receive-pack.html хук post-receive для перезаписи имени ссылки сразу после его написания, а затем что-нибудь можно было бы сделать, чтобы повернуть этот процесс вспять на обратном пути, но это кажется хрупким.У кого-нибудь есть идея получше?

---

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

типа (действительно грязно):

foreach my $user (@users) {
    my @branches = split(/s/,cat `$LDAPSERVER/$USER/$REPO/.git/refs/heads`);
    foreach my $branch (@branches) {
        system "git fetch $LDAPSERVER/$USER/$REPO/$BRANCH:+$USER$BRANCH"
    }
}

Answer 1

Зачем разработчику настаивать на omni-backup репо?

В целях резервного копирования я бы предпочел зарегистрировать репозиторий другого разработчика как удаленный и выполнить git fetch каждую ночь (с omni-backup сервер) во всех удаленных репозиториях.
Таким образом, сговор с названием ветки невозможен.И более автоматизированный процесс (разработчику не нужно явно помещать что-либо в репозиторий, с которым он/она не работает напрямую, а будет рассматривать только для резервного копирования)

Тогда я бы произвел приятную маленькую git archive снаружи omni-backup и храните его подальше.

Answer 2

Если вы можете заставить разработчиков следовать определенным рекомендациям, git push может сделать это правильно.

Если вы запускаете эту команду:

git push omni-backup feature:bob-feature

.

Если Omni-Backup является удаленным Ref для хранилища, то функция Bob's Flations будет подтолкнуть к Bob-функцию в Omni-Backup.Но если довериться, что для разработчиков нежелательно, переключение направления потока и наличие Omni-Backup, потяните репозитории разработчиков, поскольку VONC предлагает, это лучшее решение