Эффективное резервное копирование многих версий 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. Похоже, я могу использовать push hooks, зарегистрированный в http://www.kernel.org/pub/software/scm/git/docs/git-receive-pack.html post-receive hook, чтобы переписать имя ref сразу после его написания, а затем что-то можно было бы сделать, чтобы обратить вспять процесс на обратном пути, но он чувствует себя хрупким. У кого-то есть лучшая идея?

---

редактировать: для 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, вытащите репозитории разработчиков, как предлагает VonC, лучшее решение