Git workflow и rebase vs merge вопросы

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

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

clone the remote repository

git checkout -b my_new_feature

..work and commit some stuff

git rebase master

..work and commit some stuff

git rebase master

..finish the feature

git checkout master

git merge my_new_feature

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

вот рабочий процесс что я начал с

clone remote repository

create my_new_feature branch on remote repository

git checkout -b --track my_new_feature origin/my_new_feature

..work, commit, push to origin/my_new_feature

git merge master (to get some changes that my partner added)

..work, commit, push to origin/my_new_feature

git merge master

..finish my_new_feature, push to origin/my_new_feature

git checkout master

git merge my_new_feature

delete remote branch

delete local branch

есть два существенных различия (я думаю): я использую слияние всегда вместо перебазирования, и я нажимаю свою ветвь функции (и моя ветвь функции фиксируется) в удаленном репозитории.

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

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

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

Что такое" правильный " рабочий процесс для чего-то вроде этого? Git должен сделать ветвление и слияние супер-легким, и я просто не видя его.

2011-04-15 обновление

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

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

clone the remote repository

git checkout -b my_new_feature

..work and commit some stuff

git rebase master

..work and commit some stuff

git rebase master

..finish the feature, commit

git rebase master

git checkout master

git merge my_new_feature

в самом деле, наш рабочий процесс немного отличается, как мы склонны делать сквош сливает вместо необработанных слияний. (Примечание: это спорно, см. ниже.) это позволяет нам превратить всю нашу ветку функций в одну фиксацию на master. Затем мы удаляем нашу ветку. Это позволяет нам логически структурировать наши коммиты на master, даже если они немного запутаны на наших ветвях. Итак, вот что мы делаем:

clone the remote repository

git checkout -b my_new_feature

..work and commit some stuff

git rebase master

..work and commit some stuff

git rebase master

..finish the feature, commit

git rebase master

git checkout master

git merge --squash my_new_feature

git commit -m "added my_new_feature"

git branch -D my_new_feature

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

Github и Bitbucket (другие?) Вытяните Запросы - если вам интересно, как merge / rebase относится к запросам Pull, я рекомендую выполнить все вышеперечисленные шаги до тех пор, пока вы не будете готовы слиться обратно к мастеру. Вместо того, чтобы вручную сливаться с git, вы просто принимаете PR. Обратите внимание, что это не будет делать слияние сквоша (по крайней мере, не по умолчанию), но non-squash, non-fast-forward-это принятое соглашение о слиянии в сообществе запросов на вытягивание (насколько я знаю). В частности, он работает следующим образом:

clone the remote repository

git checkout -b my_new_feature

..work and commit some stuff

git rebase master

..work and commit some stuff

git rebase master

..finish the feature, commit

git rebase master

git push # May need to force push

...submit PR, wait for a review, make any changes requested for the PR

git rebase master

git push # Will probably need to force push (-f), due to previous rebases from master

...accept the PR, most likely also deleting the feature branch in the process

git checkout master

git branch -d my_new_feature

git remote prune origin

Я полюбил Git и никогда не хочу возвращаться в SVN. Если вы боретесь, просто придерживайтесь его, и в конце концов вы увидите свет в конце из туннеля.