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

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

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

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

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

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

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 svn](https://stackoverflow.com/questions/3239759/checkout-remote-branch-using-git-svn)
* [Как сообщить git-svn о удаленной ветке, созданной после того, как я взял репо?](https://stackoverflow.com/questions/296975/how-do-i-tell-git-svn-about-a-remote-branch-created-after-i-fetched-the- repo )

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

```
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

```

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



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 внутри репозитория.