ищу идеальный рабочий процесс git-svn - PullRequest
4 голосов
/ 01 августа 2010

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

Я прочитал рабочий процесс git svn - функции и слияния и несколько других сообщений, но до сих пор не ясно, как мне к нему подойти.

Как я планируюна работу: я планирую, чтобы моя ветка master была чистой от разработки и использовалась только для слияния / rebase / dcommit.

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

После того, как функция готова для совместного использования / тестирования в основном репо, яЯ объединю / перебазирую в мою основную ветку и затем dcommit в svn-repo.Я хочу иметь только одно сообщение о фиксации SVN для каждого dcommit - я хочу чаще делать коммиты с более конкретными для меня комментариями, а затем dcommit отправлять svn с сообщением для остальной части команды.Я предполагаю, что для этого я либо буду использовать git merge --squash или git rebase --interactive для этого.

Базовый поток мерзавцев, который я предусмотрел, выглядит следующим образом:

  1. // он начинается ...
    git svn clone <repo>

  2. //
    git checkout -b feature 1
    // рабочий коммит, рабочий коммит

  3. //
    git checkout -b bug-123
    // рабочий коммит, рабочий коммит
    // bug-123 закончен - готов к отправке обратно

  4. // вернулся к мастеру для шага 5
    git checkout master

  5. // получить любые изменения, сделанные другими разработчиками
    git svn rebase

  6. //
    git checkout bug-123

  7. // перебазировать ветку, поэтому у меня меньше изменений меньше.здесь не уверен ..
    git rebase master || git svn rebase
    // Предполагается, что я делаю ребаз в FF, поэтому мои коммиты являются просто аддонами к текущему репо
    // Я не знаю, перебазирую ли мастер илиsvn репо или это не имеет значения.

  8. // необходимо вернуть мои изменения мастеру для отправки
    git checkout master

  9. // добавить свои изменения в master
    git rebase bug-123 (--interactive?) || git merge --squash bug-123
    // добавить новое сообщение о коммите здесь?

  10. // отправить мои изменения обратно в команду
    git dcommit

Итак, есть несколько вопросов:

  1. Как мне получить изменения в ветке, которую я хочу зафиксировать, перебазировав основную ветвь или ветку svn

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

  3. имеет ли смысл dcommit напрямую из рабочей ветки (например, bug-123)?

  4. как мне получить изменения от bug-123 вернулся в черту-1?Я предполагаю, что сделаю это через репозиторий SVN - то есть добавленные мной изменения будут объединены, когда я сделаю ребазинг, когда придет время добавить функцию-1 в репо - но, возможно, нет.

1 Ответ

3 голосов
/ 06 августа 2010

Я не эксперт, но это мой опыт ( связанный ответ ).

  1. Думаю, это не имеет значения.Важно то, что вы перемещаете последние изменения из SVN в ветку, из которой собираетесь отправлять.
  2. Пусть другие ветви получают изменения через SVN.Если вам нужен один SVN-коммит из серии git-коммитов, сперва их нужно объединить.
  3. Думаю, это тоже не имеет значения.Вы собираетесь перебазировать последние изменения из SVN, и вам нужно получить их линейно перед вашими коммитами Git.Если вы выполните git svn rebase в master, а затем перебазируете master в ветку объектов, или наоборот, то же самое.После этого вы, вероятно, захотите удалить ветку, поскольку она выполнила свою работу (в соответствии с ограничениями SVN, вам не разрешено снова объединяться).
  4. Всегда позволяйте изменениям перетекать в другие ветви и репо через перебазирование SVN.

Просто попробуйте и попробуйте получить самый простой / практичный рабочий процесс для вас и вашей команды.Постарайтесь сделать ветки недолговечными (в любом случае SVN не получит никакого представления о них), и помните, что коммиты всегда должны быть линеаризованы в верхней части вашего журнала, прежде чем вы вернетесь назад.

...