децентрализованная разработка с использованием git и git-svn - PullRequest
6 голосов
/ 10 января 2011

У нас 2-3 небольшие команды по 2-3 человека. Мы все используем git для локальных и svn для центрального репозитория, а git-svn получил синхронизацию. Это работает все время, кроме случаев, когда мы хотим делиться нашим кодом между собой.

Итак, мы опробовали git pull, это создает много конфликтов и не обнаруживает, что мы находимся на одном дереве. Извлекает все изменения (так же, как клон, затем тянуть) Конечно, я не хочу клонировать полное репо. каждый раз, когда я хочу поделиться.

Пожалуйста, предложите лучший поток.

  1. Мы не можем избавиться от центрального свн.
  2. Мы не можем клонировать каждый раз.

Ответы [ 3 ]

3 голосов
/ 09 декабря 2011

SubGit кажется вам отличной альтернативой.

SubGit - это решение на стороне сервера, оно обеспечивает доступ Git к хранилищу Subversion и наоборот.Это означает, что вы можете работать только с Git-репозиторием, используя Git-клиент по вашему выбору.

Вам необходимо один раз установить SubGit в свой репозиторий Subversion.После этого SubGit немедленно переводит svn revision в git commit для каждого svn commit, а git commit в svn revision для каждого git push.

SubGit - это программное обеспечение с закрытым исходным кодом, но оно бесплатно для проектов с открытым исходным кодом.Для получения дополнительной информации, пожалуйста, обратитесь к Документация SubGit .

3 голосов
/ 10 января 2011

Назначьте одного члена команды в качестве «git hub», он / она синхронизируется с сервером SVN, с ним взаимодействуют другие члены команды, а не сервер SVN напрямую. Таким образом, git будет знать, что все члены команды находятся на одном дереве.

2 голосов
/ 10 января 2011

Чтобы добавить ответ Криса Хуанга-Ливера, вам нужна центральная точка для dcommit / rebase с репозиторием SVN.
Это не отрицает «децентрализованный» аспект Git, он просто позволяет каждому работать с одним «удаленным репозиторием» в качестве одного «центрального» репо (т. Е. С синхронизацией с svn)

Нет простого способа избежать бремени клонирования всего из (потенциально огромного) svn репо, потому что результирующее Git репо не может быть разбито на подмодули .
Это оставляет по крайней мере одно «решение», которое будет включать:

  • создание другого Git, кроме основного (который синхронизируется с SVN)
  • экспорт патчей из основного репо
  • применение этих патчей к каждому репозиторию Git, представляющему проект в основном репозитории Git.

Очевидно, что его нужно автоматизировать, но одна команда сосредоточится на одном этих репозиториев git в качестве своего "центрального" репо, а ответственный за синхронизацию SVN будет обновлять эти меньшие репозитории Git с помощью патчей исходя из основного (и скрытого) Git <=> репозитория SVN.

...