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


497

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

git checkout dmgr2
git pull origin master

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


1
сначала внесите все ваши изменения в ветку dmgr2. и затем укажите мастер 1.git checkout master и затем получите последние изменения 2.git pull 3.git merge dmgr2 4.git push -u origin master И затем вернитесь к своему dmgr2 5.git checkout dmgr2
mat_vee

я уже внес все свои изменения в ветку dmgr2, извините, забыл добавить это
Мэтью Колли,

1
если я выполню шаг 4, разве это не подтолкнет мои изменения в разработке в master? я не хочу этого делать
Мэтью Колли

Итак, что вы говорите, вы хотите внести изменения из вашей основной ветки в свою ветку разработки?
JcKelley

9
Переключитесь на devветку с помощью git checkout dev. Потом git pull --rebase origin master. Если вам повезет, конфликтов не будет, и у dev будут последние изменения от master.
jww

Ответы:


726

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

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 , и он не обновляет ссылку в вашем репо: 1 любые новые коммиты заканчиваются 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

например.


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


28
Я просто прошу друга - как бы вы отменили первый блок кода, который у вас здесь (checkout / fetch / merge)?
Рич Брэдшоу

10
@RichBradshaw: git checkoutобычно не является деструктивным и обычно нет причин для отмены a git fetch, поэтому звучит так, будто вы спрашиваете, как отменить коммит слияния. Ответ такой же, как и для других коммитов: либо git resetили, либо git revert. Для неопубликованных измененийgit reset обычно лучший метод; для изменения других уже есть, git revertможет быть лучше, но увидеть советы Торвальдса о возвращаясь слиянием: kernel.org/pub/software/scm/git/docs/howto/...
Торек

2
@WeDoTDD: я не понимаю вопроса. Есть целый ряд команд для просмотра фиксации графика ( gitk, git log --graphс или без --oneline, и так далее) , и вы можете git showилиgit show -m слияние совершить, или использование git diff. Во всех этих случаях вы указываете программу при вводе команды в командной строке.
Торек

1
@torek: попробовал свой путь: git checkout branch и затем git pull origin master, но он вытащил все основные изменения как одно изменение, которое должно быть зафиксировано локально, вместо того, чтобы извлекать их с их историей фиксации и сообщениями, поэтому после обновления local master и переключаясь на ветку, "git rebase master" выполняет работу со всеми конфликтами, которые нужно разрешить, а затем я добавляю к "git pull --rebase" и снова обрабатываю все конфликты, а затем git push origin branch, чтобы привести все в соответствие. Я думаю, что должен быть лучший способ для этого - я прав?
user10556443

1
@torek: я согласен, что полученный результат - утомительный процесс, который заставляет меня обрабатывать повторяющиеся ребаз и слияния & ... каждый раз, когда я хочу получить обновление от master ... Но предлагаемый способ, который, как я признаю, проще, получить все изменения в рамках одного незафиксированного изменения в локальной ветке без сохранения порядка / истории генерации. Я буду рад узнать лучшее предложение, как использовать «fetch» ​​и отслеживать мастер без необходимости использовать «pull» и т. Д.
user10556443

14

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

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

git fetch
git rebase origin/dev

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

8

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

git rebase origin/master


Не забудьте git fetch originсначала.
Ленух

3

Сценарий :

У меня есть обновление 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, чтобы папка была «чистой»

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.