2009-11-19 2 views
5

Я нахожусь в команде, использующей Git прямо сейчас, и у нас есть хороший рабочий процесс. У нас есть центральный репозиторий с двумя ветвями, dev и master. Мы создаем местные филиалы для работы над отдельными задачами. Мы сливаемся в dev, когда они готовы. Затем мы сливаемся, чтобы справиться, когда все будет готово, и мы помечаем все наши релизы. Если нескольким разработчикам необходимо более тесно сотрудничать с задачей, мы можем создать другую, возможно временную удаленную ветку, чтобы они могли совместно использовать патчи. Это очень хорошо работает для нас, но это оставляет нам две проблемы.Как управлять резервными копиями и контролировать Git с центральным хранилищем?

Одной из проблем является проблема с резервными копиями. Конечно, большая часть базы кода поддерживается. У каждой машины, имеющей клон репозитория, есть большая часть кода. Однако код, который кто-то пишет в течение дня, не подкрепляется до тех пор, пока они не сливаются с dev и не нажимают. Если задача, над которой они работают, нетривиальна, это может быть за несколько дней до того, как у них что-то слияние и толкать достойно. Как мы убеждаемся, что этот код работает в резервном копировании в центральном безопасном месте? Просто используйте какое-то резервное решение, внешнее по отношению к Git?

Вторая проблема - проблема мониторинга прогресса сотрудников. Менеджер (ы) хочет видеть, какой код разработчики написали каждый день. Если в день идет покупка, где вы ничего не выталкиваете, это будет выглядеть так, как будто вы ничего не делали весь день. Нам нужно каким-то образом ежедневно показывать нашу работу, которая не заставляет нас совершать и нажимать код, который не готов к совершению, слиянию и нажатию.

Одним из решений, которое мы рассмотрели, является создание удаленной ветви на центральном репо для каждой отдельной локальной ветви, которую мы делаем. Это, вероятно, сработает, но это будет большой беспорядок, даже если мы регулярно удаляем старые неиспользуемые ветви. Это также много дополнительной работы для управления всем этим.

Как мы можем удовлетворить эти требования бизнеса, не нарушая рабочий процесс Git?

+0

Вообще я считаю: филиал во время работы на нем толчок для резервного копирования в конце дня удалить, как только у вас нет необходимости его больше, и он был включен в основной ветви процесса работает просто отлично. – Kzqai

+0

Бах, плохо отформатированный, но вы поняли, что использование всей этой ветвящейся власти в схеме, организованной именованием, является простым и полезным. – Kzqai

ответ

3

Вы можете подумать о том, чтобы сделать что-то подобное. Используйте неинтерфейсное пространство имен для частных резервных копий разработчика. Например. refs/backups/xxx/* где xxx - идентификатор пользователя или инициалы разработчика или аналогичный.

Затем разработчик может сделать git push origin +refs/heads/*:refs/backups/xxx/* для резервного копирования всех своих местных филиалов.

По умолчанию разработчики не видят личные резервные копии друг друга, но при необходимости они могут быть восстановлены.

Формула резервного копирования может быть выполнена командой git backup через псевдоним.

Как я думаю, это не очень хорошая идея, частные ветви разработчика могут использоваться для просмотра его «прогресса», это очень похоже на микроуправление.

Редактировать: При написании это показалось мне довольно знакомым, а затем я вспомнил, почему. Я писал о чем-то подобном в ответ на другой вопрос некоторое время назад: link.

+0

Это хорошее решение для резервного копирования. Однако как кто-то может проверить мои резервные копии? – Apreche

+0

Да, для нас это «особенность» не проблема. Если вы хотите действительно частные резервные копии, вам действительно нужен отдельный резервный репозиторий для каждого пользователя. –

2
  • Резервное копирование отдельных репозиториев

  • Создание "резервного копирования" хранилище, к которому другой толчок закончил работу в refs/remotes/<username>/ имен:

    [remote "backup"] 
        url = [email protected]/srv/git/backup.git 
        push = +refs/heads/*:refs/remotes/user/* 
    
  • Использование Gerrit: см "Gerrit: Google-style code review meets git" статью на LWN.Чистая

Смежные вопросы