Наша компания использует (и поддерживает!) SVN, но я склонен использовать git. Что я хочу попробовать, так это иметь git-репозиторий - по одному на проект, разработчики проектов смогут извлекать из этого репозитория (и, конечно, извлекать друг друга, если захотят). Но я все еще хочу перенести все изменения в SVN, потому что SVN поддерживается нашей службой технической поддержки.
Я тестировал сценарий со следующими репозиториями:
- SVN-репозиторий - он поддерживается нашей компанией, и наша команда должна в любой момент отправить туда все изменения
- git-svn-clone - это git-репозиторий, клонированный из SVN выше - все разработчики проекта должны размещать здесь свои коммиты
- git-dev-clone - это git-репозиторий разработчика.
Единственная проблема с прямым использованием git svn rebase и git svn dcommit, которую я заметил, заключается в том, что после каждого перехода из репозитория git разработчика в репозиторий git-svn-clone мне приходится перебазировать репозиторий разработчика как как только изменения будут распространены в SVN и перебазированы. Чего я хочу добиться, так это избегать перебазирования после каждого толчка.
Обратите внимание, что я предполагаю, что каждый разработчик проекта будет использовать только репозиторий git, и никто не будет использовать SVN напрямую.
Мне удалось достичь этого поведения вручную, проверяя каждый коммит git по одному в репозитории 'git-svn-clone' после push и фиксируя эти изменения в SVN с помощью клиента SVN. Я полагаю, что 'git svn dcommit' делает то же самое, но он также синхронизируется с SVN и вносит изменения в идентификаторы SHA, что заставляет меня перебазировать.
Опция
P.S .: --no-rebase для git svn dcommit не помогла, поскольку после первого коммита, переданного в SVN, git svn dcommit не позволяла мне вносить больше изменений в SVN, пока предыдущий не был перебазирован. Я пробовал такое поведение один раз и, вероятно, мог что-то упустить.