«Git pull» или «git merge» между основной веткой и веткой разработки

243

У меня есть masterветка и developветка для работы над несколькими изменениями. Мне нужно объединить изменения с masterв develop, но в конечном итоге слить все из developв master. Я имею в виду два разных рабочих процесса:

git pull origin masterв developфилиал
git merge masterв developфилиал

Какой лучший способ сделать это и почему?

git workflow

— Carson
источник

18

Рекомендуемое чтение: nvie.com/posts/a-successful-git-branching-model

— Алекс Брасетвик

2

git pull= git fetch+git merge FETCH_HEAD

— Юша Алеауб

104

Будьте осторожны с ребазой. Если вы делитесь своей веткой разработки с кем-либо, rebase может сделать беспорядок. Rebase хорош только для ваших местных отделений.

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

— Эрик Лидс
источник

Тем не менее, безопасно ли перебазировать и git push origin rebasedBranch --forceна частном репо? Единственный пользователь - это я.

— k0pernikus

Да, если вы единственный пользователь, конечно, это безопасно. Я использую git push --force все время, когда я единственный пользователь. :)

— Тайлер Рик

3

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

— Ян Лотинский

Хорошая статья об использовании rebase, даже слияния после разрешения конфликтов: github.com/everpix/Everpix-Intelligence

— Ян Лотински,

@IanLotinsky ваша ссылка не указывает на статью о перебазировании. Longshot, но у вас все еще есть правильная ссылка? :)

— Даниэль Серодио

347

Этот рабочий процесс работает лучше всего для меня:

git checkout -b develop

... внести некоторые изменения ...

... мастер уведомлений обновлен ...

... совершать изменения, чтобы развиваться ...

git checkout master
git pull

... вернуть эти изменения в развитие ...

git checkout develop
git rebase master

... внести еще некоторые изменения ...

... поручить им развиваться ...

... объединить их в мастера ...

git checkout master
git pull
git merge develop

— Ян Лотинский
источник

2

Я тоже так работаю и считаю, что это хорошо работает. Есть одна вещь, которую я не делаю, и это git pullпрямо перед финалом git merge develop. Какова цель этого?

— crdx

После того, как мастер уведомлений был обновлен ... часть, разве мастер проверки не сотрет ваши локальные изменения для разработки, если вы их не зафиксировали?

— 2012 года

1

@ a1an Нет, но если вы не подтвердите их, изменения будут перенесены в основную ветку, и git не даст вам потянуть, пока они не будут зафиксированы.

— elemjay19 17.12.12

5

@crdx Скорее всего, другие ветви будут объединены с удаленным мастером, прежде чем вы добавите свою ветку к локальному. Вы вытягиваете и вносите удаленные изменения мастера в локальную копию мастера. Вот как я это понял.

— Тарун

12

git pull --rebase origin masterна вашей ветке разработки немного быстрее.

— Натан Лилиенталь

24

Вероятно, лучший подход для такого рода вещей git rebase. Он позволяет вам перенести изменения из master в вашу ветку разработки, но оставить всю вашу работу по разработке «поверх» (позже в журнале коммитов) материала из master. Когда ваша новая работа будет завершена, слияние с мастером будет очень простым.

— divegeek
источник

10

Хороший совет, при условии, что developникто не поделится.

— Карл Билефельдт

1

@KarlBielefeldt Если develop мы расскажем об этом другим участникам, как бы мы обновились, developкогда некоторые исправления были загружены напрямую master? Должны ли мы сделать слияние, то есть git checkout master && git pull --rebase && git checkout develop && git merge master? Я оставил комментарий к ответу с наибольшим количеством голосов выше, в котором также подробно описана эта проблема.

— модуль

5

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

> git clone git://<remote_repo_path>/ <local_repo>
> cd <local_repo>
> git checkout -b develop
....do a lot of work on develop
....do all the commits
> git pull origin master
> git rebase master develop

Вышеуказанные шаги гарантируют, что ваша ветвь разработки всегда будет в курсе последних изменений из основной ветки. Как только вы закончите с разработкой ветки, и она вернется к последним изменениям на master, вы можете просто объединить ее:

> git checkout -b master
> git merge develop
> git branch -d develop

— Kirpich
источник

1

мое эмпирическое правило таково:

rebaseдля веток с тем же именем , в mergeпротивном случае.

примеры же имена будут master, origin/masterи otherRemote/master.

если developсуществует только в локальном репозитории, и он всегда основан на недавнем origin/masterкоммите, вы должны вызвать его masterи работать там напрямую. это упрощает вашу жизнь и представляет вещи такими, какие они есть на самом деле: вы непосредственно развиваетесь в masterотрасли.

если developиспользуется общий доступ, он не должен быть перебазирован master, просто объединен с ним --no-ff. вы развиваетесь на develop. masterи у developнас разные имена, потому что мы хотим, чтобы они были разными и оставались отдельными. не делайте их такими же rebase.

— hoijui
источник