Будет ли работать этот рабочий процесс git-svn? - PullRequest
Новая
       2

Будет ли работать этот рабочий процесс git-svn?

9 голосов
/ 07 декабря 2010

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

  1. (master) $ git svn init <path>
  2. (master) $ git svn fetch
  3. (master) $ git svn rebase
  4. (master) $ git checkout -b topic-branch
  5. (topic-branch) $ # HACK HACK COMMIT HACK HACK HACK COMMIT HACK COMMIT
  6. (topic-branch) $ git checkout master
  7. (master) $ git merge topic-branch - это ускоренное слияние, поэтому фиксация слияния отсутствует
  8. (master) $ git svn rebase
  9. (master) $ # fix conflicts
  10. (master) $ git svn dcommit
  11. GOTO 4

Ответы [ 3 ]

5 голосов
/ 07 декабря 2010

Да, это по сути то, что я делаю при работе с репозиториями Subversion.Ключом к простоте этого является сохранение локальных веток Git и вообще не пытаться сопоставлять их с ветвями Subversion.

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

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

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

2 голосов
/ 15 февраля 2011

Из моего краткого опыта я внес небольшие изменения в ваш рабочий процесс и добавил комментарии:

  1. (master) $ git svn init <path> (или (master) git svn clone <url>)
  2. (master) $ git svn fetch
  3. (master) $ git svn rebase (начало цикла, разрешение конфликтов)
  4. (master) $ git checkout -B topic-branch ( осторожно перед этим)
  5. (topic-branch) ## HACK HACK COMMIT HACK COMMIT (используйте стороннюю организацию)
  6. (topic-branch) $ git checkout master
  7. (master) $ git rebase topic-branch (разрешение конфликтов)
  8. (master) $ git svn rebase (разрешение конфликтов, если есть)
  9. (master) $ git svn dcommit ( внимательно читаем здесь)
  10. GOTO 3 (или 4, если нет необходимости перезагружать)

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

Подробнее о внесенных корректировках:

  • Внимание на заглавную -B на шаге 4, он сбросит ветку темы, поэтому он всегда новый из текущей SVN. без этого цикл оборвался бы, выдав ошибку «ветвь уже существует».
  • Шаг 7, используя rebase вместо merge. да, это, вероятно, будет быстрое слияние, но это лучше, чем потом сожалеть. Представьте, что что-то делается между шагами 6 и 7.
  • Цикл 3 вместо 4. Кроме того, просто чтобы играть на безопасной стороне. Похоже, использование svn rebase никогда не является злоупотреблением, и, поскольку оно всегда выполняется на главном сервере, всегда есть ветки в качестве резервной копии.
0 голосов
/ 16 декабря 2010

Безопасно, если вы, выполняя шаги 5, никогда не переключаетесь на master и не выполняете "git svn rebase".В противном случае я бы порекомендовал сделать «мастер git rebase» между шагами 5 и 6.

...