Ищу идеальный рабочий процесс git-svn

Question

Компания, с которой я работаю, работает с 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
   // работа коммит, работа коммит
   // ошибка 123 завершена - готово к отправке обратно

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

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

6. //
   git checkout bug-123

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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