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