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

Я использую 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. я 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

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

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

Источник

7 ответов

Решение

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

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

Источник

У меня возникла такая же проблема (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
Источник

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

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

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

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

    / workspace / wikka (featurebranch1 | REBASE-i) $

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

Источник

Подход SubGit может быть немного проще:

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

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

Для получения более подробной информации, пожалуйста, обратитесь к документации SubGit и сравнению git-svn.

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

Источник

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

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

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

Источник

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

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

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

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

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

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

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

Источник

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

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

Чтобы объединить, переключитесь на транк и выполните:

git svn rebase

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

git rebase

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

Источник
Другие вопросы по тегам