git-svn и git имеют одинаковую функциональность при работе локально. Разница появляется при отправке или получении изменений из удаленного хранилища.
Push vs. dcommit.
Зачем git-svn нужна эта отдельная команда dcommit?
Поскольку хранилище Subversion ведет себя иначе, чем удаленное хранилище Git: SVN всегда пытается объединить входящие изменения на уровне каталогов. Если кто-то изменяет файл, который был изменен одновременно другим пользователем, SVN отклоняет входящие изменения с ошибкой устарела . В противном случае commit / dcommit проходит.
В противоположность этому, Git push возвращает устаревшую ошибку, когда кто-либо изменяет одну и ту же ветку / тэг, независимо от того, к каким файлам были применены.
В результате git-svn dcommit должен убедиться, что только что принятая версия совпадает с ожидаемой (некоторые каталоги могут быть автоматически объединены во время dcommit). Это означает, что git-svn всегда извлекает / возвращает обратно только что отправленные изменения в репозиторий SVN.
Файл игнорируется.
Когда кто-то игнорирует определенные файлы в рабочем дереве и фиксирует эту модификацию, нет способа отправить эту модификацию с git-svn dcommit. Таким образом, нет возможности поделиться игнорированием с другими пользователями репозитория SVN.
Атрибуты Git.
И Subversion, и Git имеют определенные метаданные, связанные с файлами и каталогами. Как и .gitignore, нет возможности поделиться .gitattributes с коллегами.
Слияние совершается.
Наконец, когда кто-то пытается dcommit сделать коммит слияния, есть вероятность, что определенные коммиты вообще не будут отправляться в репозиторий SVN. Это происходит, когда все коммиты объединенной ветви еще не были переданы в репозиторий SVN.
Большинство из этих git-svn проблем трудно или даже невозможно исправить. Вы можете рассмотреть SubGit - альтернативу git-svn на стороне сервера, которая исправляет большинство из них.
Подробнее см. Документация SubGit и Сравнение SubGit с git-svn .