Git с сундуком и ветвями SVN

Поскольку я использовал Git, мне понравился тот факт, что вы можете создать локальную ветвь, которую вы можете сквоить в свою основную ветку и DCommit на SVN (на внешней линии), а затем удалить эту локальную ветвь (в Git).

Теперь я хочу узнать, как работать с ветвями SVN. Мне нужно работать с командой по новой функции, но мы не хотим делать это на Trunk. Поэтому очевидно, что нам нужно отделяться от ствола и работать над этой веткой, пока мы не будем довольны работой и не сможем вернуться к Trunk.

Любые идеи о том, как это сделать с точки зрения Git front-end? Я уверен, что есть много ресурсов, но я не нашел того, что объясняет это мне.

Поэтому, чтобы убедиться, что я объясняю себя, я знаю, как использовать Git только с SVN. Это легко и удобно. Но мне нужно подключиться к SVN из магистрали и использовать Git для работы над этой веткой (хотя мы надеемся, что до сих пор у нас есть доступ к SVN-тубу с Git), пока работа не будет выполнена, а затем слейте эту ветку обратно в trunk на SVN (снова используя Git). Если кто-нибудь может дать мне понять, я был бы ОЧЕНЬ благодарен! Возможно ли это в рамках одного Git-репо?

Заранее спасибо. (Если это еще не ясно, сообщите мне).

1
nl ja de
добавлено автор Daniel Hilgarth, источник
Спасибо за комментарий. Но как будет работать слияние? Такой же? Это меня беспокоит.
добавлено автор Dandré, источник

2 ответы

I blogged about this topic a few months ago: http://www.jillesvangurp.com/2012/08/04/git-presentation/

Короче говоря, вы можете отслеживать несколько ветвей svn в одном репозитории git, но вы действительно не должны этого делать. Перепутавшись однажды, я бы никогда больше не пытался отслеживать несколько ветвей svn в одном репозитории. Это слишком изменчиво и слишком легко нанести серьезный урон в svn. В основном все казалось прекрасным локально, и я выполнил свои изменения. Но на самом деле я переупорядочил некоторые коммиты, которые действительно не должны были переупорядочиваться и наносили большой урон вверх по течению. В конце концов, мне пришлось сделать большой возврат svn. Очень неловко.

Таким образом, вместо этого работайте с отдельными репозиториями git, чтобы отслеживать каждую ветвь svn и использовать эти репозитории как удаленные в репозитории git только там, где вы фактически работаете с нажатием на разные удаленные репозитории. Изоляция git и svn, как это, имеет большой смысл. Удостоверьтесь, что ваша история линейна (svn не делает нелинейной), и всегда будьте осторожны с восходящим потоком.

Более безопасный способ переместить фиксации между ветвями/репозиториями (то же самое в мире git) в этом контексте - использовать git format-patch и git am. Кроме того, вы можете использовать git cherry-pick внутри репозитория.

3
добавлено
+1 для утверждения «Изоляция git и svn, как это имеет большое значение». Их модели разветвления разные. Мы не должны заставлять себя думать слишком много.
добавлено автор kakyo, источник
Для вашей конкретной проблемы: 1) работа с git svn clone of trunk и вашей svn-веткой; 2) движение совершает переход между двумя, используя git format-patch и git am. Это изолирует две ветви, и единственным недостатком здесь является отсутствие поддержки свойств, связанных с слиянием в svn.
добавлено автор Jilles van Gurp, источник
Спасибо Джилле. Я прочитаю его позже, когда у меня будет время. Я просто пытаюсь понять, что лучше всего подходит для такого рода вещей. Git действительно полезен для меня, я просто не хочу испортить исходное репо. Вот почему я задал этот вопрос (наверху).
добавлено автор Dandré, источник
Я, наконец, установил Visual SVN-сервер на своей машине, чтобы играть вокруг слияния и ветвления на SVN с помощью Git, и поэтому я опубликовал свой ответ ниже моих результатов.
добавлено автор Dandré, источник

I have finally discovered what I need to do in order to work with SVN branches using Git. I have tried the stuff mentioned below (except where I specify) so I am fairly confident that as long as I don't do anything funny or out of line, my commits from Git to SVN should work just fine. But of course I don't take any responsibility for any problems that might occur! I am open for further comments/remarks.

Даже если я не клонирую репо SVN со стандартным макетом, у меня должны быть настроены настроенные пульты, которые указывают на соответствующие пути SVN при подрывной работе.

Чтобы клонировать ветвь SVN (путь SVN должен указывать на корневой путь, содержащий сундук, ветки и теги):

git svn clone -s http://myrepo.com c:/my/local/path

Если у вас уже есть клон ветки SVN, вам нужно вручную добавить удаленные объекты в другие ветви SVN, проверьте их:

Важно то, что у вас есть локальный филиал, который отслеживает удаленную ветку.

git checkout -b localbranch remotes/remote_branch

Теперь вы можете совершить против этого локального филиала, и каждый раз, когда это делается, делайте это так же, как в сундуке:

git svn fetch
git svn dcommit

Когда вы, наконец, закончите эту ветвь SVN, и вы захотите объединиться с багажником, вы можете сделать следующее (он берет все из этой ветки и переустанавливает ее на главный):

git checkout master
git merge localbranch
git rebase -i trunk  (just save the message)
git svn fetch
git svn dcommit

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

git merge --squash localbranch
git svn fetch
git svn dcommit

Возможно, вы делаете сухой пробег, прежде чем делать настоящий DCOMMIT, чтобы убедиться, что все в порядке (включая пункт назначения).

git svn dcommit -dry-run

Однако, если вы ожидаете конфликтов слияния (это то, что я читал в Интернете, но я не пробовал это, о чем я только упоминаю), выполните следующие действия перед строкой git checkout master , показанной выше. Это локальная ветвь, которая не отслеживает удаленное отделение, которое должно использоваться для решения конфликтов слияния и прочее. Нужно ли это еще одна история.

git checkout -b merge_work master
git merge localbranch
git checkout master
git rebase merge_work

Я пишу это для себя и для других людей, которые могут захотеть попробовать это в будущем.

1
добавлено
Я обнаружил, что единственное, что является выдающимся, это то, что он не создает файл метаданных, который использует подрывная программа, чтобы сказать, что одна ревизия была объединена с другой.
добавлено автор Dandré, источник
Git — русскоговорящее сообщество
Git — русскоговорящее сообщество
588 участник(ов)

Обсуждаем git, его фичи, хаки, надстройки и экосистему. Правила: http://telegra.ph/ru-chat-rules-06-19 https://git.wtf/

pro.git::next
pro.git::next
44 участник(ов)

Обсуждение системы контроля версий git и инструментов для работы с ней.