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

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

  1. git pull origin master в develop ветка
  2. git merge master в develop ветка

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

Источник

6 ответов

Решение

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

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

Источник

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

git checkout -b develop

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

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

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

git checkout master
git pull

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

git checkout develop
git rebase master

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

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

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

git checkout master
git pull
git merge develop
Источник

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

Источник

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

> 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
Источник

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

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

примеры для тех же имен будут master, origin/master а также otherRemote/master,

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

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

Источник

Я предпочитаю использовать git pull origin <branch_name>перейти к той ветке, с которой я хочу слиться. Я на самом деле никогда не использовал git merge <branch_name>

Причина, у меня была ошибка с ним в GitLab, когда я начинал его использовать. Но теперь это тоже более логично ... потому что git pull делает: (а) git fetch (б) git merge

2 команды против одной; делает это простым приложением для быстрой работы.

PS: если вы не уверены, что может произойти, возможно, лучше использовать команды «разбитый» прямо там;)

Источник
Другие вопросы по тегам