Разрешение Git Svn конфликтов

Question

Я использую Git-Svn для взаимодействия с хранилищем Svn на работе, и я не могу найти способ эффективно разрешать конфликты на всю жизнь. Я читал другие вопросы по этой теме, но, очевидно, мне нужно что-то еще более коррективное, потому что я всегда оказываюсь в каком-то бесконечном цикле. Я перезагружаюсь, использую mergetool (meld) для разрешения моих конфликтов и, когда дохожу до конца всего этого, я пытаюсь выполнить dcommit и получаю конфликт слияния во время ошибки фиксации.

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

Моя настройка:

У меня есть удаленный филиал (svn / trunk), локальный филиал (trunk) и другой локальный филиал, в котором я обычно работаю (working-trunk). транк был извлечен из svn / trunk, а рабочий транк был извлечен из trunk.

Вот что я делал:

1. На моем сундуке git svn rebase (возвращает конфликты)
2. git mergetool
3. [разрешить конфликты для этого файла]
4. Сохранить объединенный файл из слияния и закрыть слияние.
5. git add .
6. git rebase --continue
7. [промыть, повторить]
8. Если я получаю сообщение с вопросом, использовал ли я git add, я git rebase --skip

Когда я заканчиваю все зарегистрированные изменения, все просто останавливается, и я думаю, может быть, я не уверен, что делать в этот момент. Git не показывает ничего, чтобы быть совершенным, и я, кажется, вернулся в багажник. Затем Git позволяет мне выполнять коммит, но если я сразу же после этого пытаюсь выполнить перебазирование, я в конечном итоге заново разрешаю только что разрешенные конфликты.

Здесь явно есть критическая часть, которую я пропускаю, но я просто ее не вижу, и это вызывает много проблем и разочарований. Слияния в Git могут быть простыми, но я не уверен, что это так.

Спасибо.

ОБНОВЛЕНИЕ: Просто хотел выпустить быстрое обновление, чтобы описать мой рабочий процесс на случай, если это часть (или все) проблемы.

Для начала, после клонирования моего хранилища с префиксом svn/, у меня есть удаленная ветка svn/trunk. Учитывая, что:

1. Я git co -b trunk svn/trunk чтобы проверить мой пульт в местном филиале.
2. I git co -b working-trunk для создания рабочей ветви, которую я использую для создания еще одной степени разделения, чтобы моя локальная магистраль всегда могла отражать мою удаленную магистраль.
3. Я удаляю основную ветку по умолчанию (при работе с svn мне легче думать в терминах "trunk", а не "master").

После того, как у меня есть все мои ветви, мой типичный рабочий процесс выглядит так:

1. На рабочий ствол , я делаю свои изменения и фиксирую их.
2. Я git co trunk и делаю git svn rebase.
3. Предполагая, что новый код был перебазирован, я git rebase working-trunk.
4. git co working-trunk
5. git merge trunk
6. git rebase trunk
7. git co trunk
8. git merge working-trunk
9. git svn dcommit

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

Еще раз спасибо.

Answer 1

Я бы рекомендовал использовать git rebase вместо git merge. Svn ведет линейную историю и, кажется, иногда путается со слиянием веток git. Использование git rebase гарантирует, что SVN понимает линейную историю.

см: http://learn.github.com/p/git-svn.html для получения дополнительной информации и рекомендаций.

Answer 2

У меня возникла такая же проблема (git svn rebase, который возвращает конфликты). Я обнаружил проблему в моем рабочем процессе. Вот рабочий процесс, которому я / вы должны следовать:

git svn rebase # put all the new commits on top

git svn dcommit # push the new commits to svn (will rewrite each commit message to add the svn tag)

git pull # merge the conflicts due to the commit messages

git push # push the synchronized version to the remote git server

Всякий раз, когда я забывал объединить историю после dcommit, у меня возникают новые (поддельные) конфликты, которые появляются, если я делаю новые коммиты. Чтобы решить их, вы можете либо следовать описанному выше подходу, либо, если это связано с той же проблемой, что и я, вы также можете сделать это автоматически, используя:

git svn rebase --strategy ours

Answer 3

Можно найти подход SubGit немного проще:

1. Установить SubGit в хранилище Subversion на стороне сервера
2. Используйте git, а не git-svn, чтобы отправить изменения в репозиторий SVN *

При установке SubGit создается Git-аналог репозитория SVN. Клонируйте этот репозиторий в ваш локальный; создавайте любые ветви и отправляйте их в удаленный репозиторий Git, SubGit автоматически преобразует эти ветви в SVN.

Подробнее см. В Документация SubGit и сравнение git-svn .

* Работает с любым Git-клиентом.

Answer 4

Я только что столкнулся с этой проблемой при использовании рекомендуемого рабочего процесса, поэтому я думаю, что у нас нет ответа здесь.

Вот как я попал в эту ситуацию.

У меня есть git-репозиторий через git svn, использующий инфраструктуру Apache.

У меня есть местное отделение.

Я пытаюсь следовать этой процедуре:

1) перебазировать багажник. 2) объединить сундук в частную ветку. 3) делай работу. 4) перебазировать багажник. 5) слить частное в багажник. 6) dcommit.

Однако я все испортил и забыл перенести переход с частного на транк. Затем я внес ряд других изменений в свою частную ветвь и оказался в цикле «промывай и повторяй» совершенно ложный конфликт. Последнее изменение, которое я выдвинул, было закомментировать одну строку. Когда я затем удалил эту строку в пренебрегаемом изменении, это привело к конфликту, который не разрешится, несмотря ни на что. В конце концов я использовал --skip на нем.

Answer 5

Я бы порекомендовал использовать git-svn только между вашей локальной trunk и удаленной trunk . Между вашей локальной магистральной и локальной mytrunk , придерживайтесь стандартных функций git only. Вы могли бы попробовать такой рабочий процесс:

[SVN]---git-svn---[trunk]---branch---[mytrunk]

Для объединения переключитесь на Магистраль и выполните:

git svn rebase

Это извлекает изменения из пульта и объединяет его с trunk . Затем переключитесь на mytrunk и выполните:

git rebase

Это извлекает изменения из trunk и объединяет их с mytrunk . Я думаю, что это должно работать. В противном случае, просто git-клонировать локальный ствол и вместо этого работать с клоном.

Answer 6

Кажется, что-то работает не так, как вы думаете. Если это не маловероятные вещи, которые предложил Хэнк Гей, то это еще одна невероятная вещь.

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

1. git branch только для того, чтобы подтвердить, что ваша структура филиала соответствует вашим ожиданиям

2. Добавить
   export PS1='\e[0;31m\n\w$(__git_ps1 "(%s)") $ \e[m'
   в ~ / .bash_profile и войдите снова,
   чтобы показать ветку (и любую внутрипроцессную команду git) в вашем приглашении:

   / рабочая область / wikka (featurebranch1 | REBASE-i) $

Это даст вам больше отзывов (и, возможно, исключит эту WAG как возможную).

Answer 7

Я попытался сделать это с (n, по-видимому, небольшим) конфликтом, который я вызвал, и после git svn dcommit у меня больше не было конфликтов. Разница лишь в том, что я не получил сообщение о git add. Возможно ли, что ваша команда просто посылает много коммитов, которые конфликтуют с вашей работой? Это кажется маловероятным, но, похоже, это самое простое объяснение.

Возможно, стоит потратить время на то, чтобы снова поставить репо в другое место и проверить, можете ли вы вносить неконфликтные изменения, чтобы убедиться, что на этапе dcommit, который каким-то образом скрыт, не возникает проблема связи.

ОБНОВЛЕНИЕ: Еще одна мысль, которая у меня возникла: я сделал git add foo.bar, когда закончил разрешать конфликт. Возможно ли, что git add . делает что-то неожиданное? Я не сильно расширяю возможности git svn, так что это в значительной степени WAG.