Git тянуть от мастера в ветку разработки

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

git checkout dmgr2
git pull origin master

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

Ответ 1

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

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 ( "ах, да, это на самом деле то, что я хочу" ), и иногда это полезно для полного изменения стратегий ( "whoa, я не хочу, чтобы это было еще" ).

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

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

git checkout dmgr2
git pull origin master

команда pull указывает git на запуск git fetch, а затем моральный эквивалент git merge origin/master. Так что это почти то же самое, что делать два шага вручную, но есть некоторые тонкие различия, которые, вероятно, не слишком относятся к вам. (В частности, шаг fetch, выполняемый pull, выводит только origin/master, и он не обновляет ref в вашем репо: 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 Эта вторая часть была изменена - я говорю "fixed" -in git 1.8.4, которая теперь оппортунистически обновляет ссылки "удаленной ветки". (Это было, как отмечается в примечаниях к выпуску, преднамеренное дизайнерское решение, чтобы пропустить обновление, но выясняется, что больше людей предпочитают, чтобы git обновлял его. Если вам нужен старый SHA-1 с удаленной ветвью, по умолчанию он будет сохраняется и восстанавливается с помощью reflog. Это также позволяет использовать новую функцию git 1.9/2.0 для поиска восходящих багов.)

Ответ 2

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

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

git fetch
git rebase origin/dev

Ответ 3

Сценарий:

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

Решение:

git checkout master    
git pull --rebase    
git checkout Mybranch    
git rebase master
git push -f origin Mybranch
  • необходимо разрешить все конфликты с помощью git mergetool & amp;, git rebase --continue, git rebase --skip, git add -u, в соответствии с ситуацией и подсказками git, до тех пор, пока все не будет решено

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

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

Ответ 4

Это сработало для меня. Чтобы получить последний код от мастера в мою ветку

git rebase origin/master