Вопросы о рабочем процессе для команды, использующей репозиторий git -svn

Я читаю пчел на git и git -svn. Я новичок в git, но мне удалось создать некоторые базовые репозитории. Однако я немного смущен тем, как будет работать рабочий процесс для git -svn, который используется командой. Цель состоит в том, чтобы преобразовать svn в git для целей ветвления и совместного использования, а затем вернуть обратно к основному репозиторию svn, когда он готов к производству. Вот мои вопросы:

Если каждый член команды создает репозиторий git из репозитория svn? Будет ли этот подход работать при слиянии с svn/pulling друг от друга?

-или -

Если из svn создается один репозиторий git, то это репо нажимается "публично" для клонирования членов команды? Затем будут ли изменения возвращены к исходному репозиторию git для перезагрузки и нажатия на svn?

-или -

Можем ли мы сделать то же самое, что и выше, кроме как просто перетаскивать изменения друг из друга в рабочую копию репо?

-или -

Я добавляю слишком много сложностей в рабочий процесс и должен просто использовать svn, так как это не возможность просто полностью конвертироваться в git?

Ответ 1

Я делаю что-то в этом направлении все время. Здесь у нас есть репозиторий svn, но несколько человек предпочитают использовать git. У нас только один человек создал репозиторий git, и тогда мы все разделили это между собой (вместо того, чтобы каждый создавал свою собственную копию git -svn), первоначальный импорт занял более 30 часов). Теперь любой, кто хочет, может просто работать в git и git svn dcommit, чтобы вернуть свои изменения в "реальный" репозиторий svn.

Ответ 2

Есть ли у разработчиков когда-либо необходимость локального репо, не имея возможности подключиться к основному репо? (т.е. кодирование на плоскости на ноутбуке)

Если нет, то я бы вообще избежал этой головной боли и просто использовал SVN с ветвями, специфичными для dev.

Однако, если вам действительно нравится распределенный подход git, я бы воспользовался третьим вариантом:

Если необходимо создать один репозиторий gitsvn, то это репо толкается "публично" для клонирования членов команды? Затем изменения будут перенесены на первоначальный репозиторий git для перезагрузки и нажатие на svn?

Можем ли мы сделать то же, что и выше, кроме просто тяньте изменения друг от друга рабочая копия репо?

Это должно работать нормально.

Ответ 3

Подумайте о том, что каждый пользовательский репозиторий git является причудливым клиентом Subversion, особенно как тот, с которым легко обмениваться версиями без привлечения центрального репозитория. Тогда каждый должен делать то, что кажется лучшим и правильным для них.

Вы также можете подумать о репозитории Subversion как о причудливом репозитории git.

Если из svn создается один репозиторий git, то это репо нажимается "публично" для клонирования членов команды? Затем будут ли изменения возвращены к исходному репозиторию git для перезагрузки и нажатия на svn?

Я не думаю, что это необходимо, потому что git svn clone работает в основном так же, как git clone.

Самое главное, чтобы сделать всегда сделать git svn rebase перед тем, как сделать git svn dcommit. Если вы делаете большой обмен версиями между репозиториями git, вероятно, неплохо изучить изменения, которые вы собираетесь использовать для Subversion, прежде чем делать это git svn dcommit.

Ответ 4

Git -svn легко поддерживает то, что вы хотите сделать. Я бы рекомендовал, чтобы каждый разработчик создал собственный репозиторий Git из репозитория Subversion (git svn clone). Разработчики могут тянуть друг от друга, если они захотят, включая обе фиксации, которые уже были перенесены на Subversion, и те, которые этого не сделали.

git -svn эквивалент svn update равен git svn rebase, что эффективно выполняет операцию git rebase против Репозиторий Subversion. Любые сообщения, которые вы, возможно, готовы совершить, которые уже были совершены кем-то другим, автоматически пропускаются.