git pull от мастера в ветку разработки

У меня есть ветка с именем dmgr2 (разработка), и я хочу извлечь из основной ветки (живой сайт) и включить все изменения в мою ветку разработки. Есть лучший способ сделать это? вот что я планировал сделать после внесения изменений:

git checkout dmgr2
git pull origin master

это должно потянуть живые изменения в мою ветку разработки, или я ошибаюсь?

Шаги, которые вы перечислили, будут работать, но есть более длинный путь, который дает вам больше возможностей:

git checkout dmgr2      # gets you "on branch dmgr2"
git fetch origin        # gets you up to date with origin
git merge origin/master

fetchКоманда может быть сделано в любой момент до того , как merge, например, вы можете поменять порядок выборки и контроль, потому что fetchпросто переходит к имени удаленного ( origin) и говорит ему: «Дай мне все , что вы есть , что я не ", т. е. все коммиты на всех ветках. Они копируются в ваш репозиторий, но именуются origin/branchдля любой ветви, названной branchна удаленном компьютере.

На этом этапе вы можете использовать любого зрителя ( git log, gitkи т. Д.), Чтобы увидеть «что у них есть», чего нет у вас, и наоборот. Иногда это полезно только для Warm Fuzzy Feelings («ах, да, это на самом деле то, что я хочу»), а иногда это полезно для полного изменения стратегии («ааа, я пока не хочу ЭТОГО»).

Наконец, mergeкоманда берет данный коммит, который вы можете назвать как origin/master, и делает все возможное, чтобы ввести этот коммит и его предков, в любую ветвь, в которой вы находитесь, когда вы запускаете merge. Вы можете вставить --no-ffили --ff-onlyпредотвратить ускоренную перемотку вперед или объединить, только если результат ускоренной перемотки вперед, если хотите.

Когда вы используете последовательность:

git checkout dmgr2
git pull origin master

то pullкоманда инструктирует мерзавец для запуска git fetch, а затем моральный эквивалент git merge origin/master. Так что это почти то же самое, что делать два шага вручную, но есть некоторые тонкие различия, которые, вероятно, не слишком касаются вас. (В частности, fetchшаг, выполняемый by, pullпереносит только origin/master , и он не обновляет ссылку в вашем репо: ¹ любые новые коммиты заканчиваются FETCH_HEADссылками только по специальной ссылке.)

Если вы используете более явный git fetch origin(затем, при желании, посмотрите вокруг), а затем git merge origin/masterпоследовательность, вы также можете обновить свою локальную masterверсию с помощью удаленного устройства, выполнив только один fetchзапуск по сети:

git fetch origin
git checkout master
git merge --ff-only origin/master
git checkout dmgr2
git merge --no-ff origin/master

например.

¹ Эта вторая часть была изменена - я говорю «исправлено» - в git 1.8.4, который теперь обновляет ссылки на «удаленные ветви» оппортунистически. (Как было отмечено в примечаниях к выпуску, это было обдуманное решение о дизайне, чтобы пропустить обновление, но оказалось, что все больше людей предпочитают его обновлять. Если вы хотите использовать старую удаленную ветвь SHA-1, по умолчанию она сохраняется в и, таким образом, могут быть восстановлены из журнала reflog. Это также позволяет использовать новую функцию git 1.9 / 2.0 для поиска исходных версий.)

Ситуация : Работа в моем местном филиале, но я люблю постоянно обновлять в ветке разработки с именем dev.

Решение : Обычно я предпочитаю делать:

git fetch
git rebase origin/dev

Это сработало для меня. Для получения последнего кода от мастера в мою ветку

git rebase origin/master

Сценарий :

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

Решение :

git checkout master    
git pull --rebase    
git checkout Mybranch    
git rebase master
git push -f origin Mybranch

• необходимо разрешить все конфликты с помощью git mergetool &, git rebase --continue, git rebase --skip, git add -u, в зависимости от ситуации и подсказок git, пока все не будет решено

(исправление к последнему этапу, любезно предоставленное Цаи Коэном, с помощью «-f» заставляет git «обновлять историю» на сервере)

теперь ветвь должна быть выровнена с master и перебазирована, также с удаленным обновлением, поэтому в git log нет «позади» или «forward», просто нужно удалить все локальные конфликтные файлы * .orig, чтобы папка была «чистой»