Как перебазировать локальную ветку с удаленного мастера

934

У меня есть клонированный проект из главной ветки из удаленного хранилища remote_repo. Я создаю новую ветку, и я фиксирую эту ветку. Другие программисты подтолкнули к remote_repoосновной ветке.

Теперь мне нужно переназначить мою ветку RB на remote_repomaster.

Как это сделать? Какие команды набрать на терминале?

Дамир
источник
14
Для меня этот вопрос неоднозначен, так как «с» может означать перебазирование в любом направлении. Глядя на ответы, я вижу, что цель состоит в том, чтобы перенести вашу ветку на удаленный мастер, а не наоборот. Я упоминаю об этом на случай, если кто-то последует ответу ниже и получит обратное тому, что он хочет.
Гленн Лоуренс
8
@GlennLawrence Я думаю, что лучше отредактировать исходный вопрос, чем добавить комментарий. Это также поощряется стековым потоком. Кроме того, перебазирование мастера на RB, вероятно, все равно не удастся, потому что RB зависит от истории мастера.
Даниэль Куллманн

Ответы:

1245

Сначала выберите новый мастер из репозитория upstream, а затем перебазируйте вашу рабочую ветку на это:

git fetch origin            # Updates origin/master
git rebase origin/master    # Rebases current branch onto origin/master

Обновление : пожалуйста, смотрите ответ Пола Дрейпера для более краткого способа сделать то же самое - последние версии Git предоставляют более простой способ сделать эквивалент вышеупомянутых двух команд.

Фрерих Раабе
источник
16
это единственный ответ, который на самом деле делает то, что просили
kayaker243
5
@ kayaker243 Нет, это то же самое, что и ответ Пола Драпера, но в полной форме, я думаю.
Эрик
7
@erik Обратите внимание, что Пол Дрейпер написал свой ответ примерно через полгода после комментария kayaker243 (и почти через два года после этого ответа).
Фрерих Раабе
3
Я получаю следующее: Your branch and 'origin/b1' have diverged, # and have 3 and 2 different commits each, respectively.Похоже git pull, нужен другой . Это правильно или я что-то здесь упускаю?
Дрор
2
@RGC Нет, git rebase masterне будет делать ту же работу , как второй команды ( git rebase origin/master) , так masterи origin/masterвполне может указывать на различные фиксаций (особенно с учетом того, что первая команда была git fetch origin, которая может изменить origin/master).
Фрерих Раабе
816
git pull --rebase origin master
# where --rebase[=(false|true|merges|preserve|interactive)]
Пол Дрэйпер
источник
19
(Эквивалентно ответу Фрерича)
Пол Дрейпер
12
Разве это не немного отличается от ответа Фрерича, в том, что он передаст изменения от исходного мастера на локального мастера, тогда как ответ Фрериха не затронет локального мастера? (извлечение против извлечения)
Джимми Хуч
7
Нет, в ответе Фрерича, ребаз изменяет локального мастера. Pull --rebase - это то же самое, что и выборка с последующей перебазировкой
adhominem
9
К вашему сведению, вы можете делать интерактивные перебазирования сgit pull --rebase=interactive origin master
emmby
14
@adhominem - я проверил документацию git-pull и не вижу ничего, подтверждающего утверждение об изменении локального мастера. Если я нахожусь на ветке с именем devи запускаю git pull --rebase origin master, то devбудет изменена только ветка , а не master. Документация --rebaseфлага гласит, что он пытается rebase the current branch on top of the upstream branch after fetchingи ничего не делает для изменения локальных ветвей отслеживания.
Восстановить Монику 2331977
227

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

git checkout master
git pull origin master

Затем оформите свою ветку и внесите изменения master:

git checkout RB
git rebase master

... или две последние команды в одной строке:

git rebase master RB

При попытке вернуться назад origin/RB, вы, вероятно, получите ошибку; если вы работаете только один RB, вы можете принудительно нажать:

git push --force origin RB

... или, если вы правильно настроили git:

git push -f
CharlesB
источник
4
при попытке вернуться к origin / RB вы, вероятно, получите ошибку. Если вы работаете только с RB, вы можете использовать git push --force origin RB. источник: stackoverflow.com/questions/8939977/…
Джои Барух,
1
Ах .... у меня именно это. мой "RB" правильно перебазирован, но я получаю бесконечные ошибки при попытке подтолкнуть его после перебазирования. Помимо push --force origin RB - есть ли «более хороший» (необязательный) способ сделать это? Я просто пытаюсь понять восприятие мерзавцев здесь - и не удается.
Мотти Шнеор
2
@MottiShneor Нет, нет хорошего способа. Если кто-то еще подтолкнет к ветке, их изменения будут потеряны! Если вы хотите быть в курсе истории коммитов git, вам лучше объединить master с вашей веткой, что безопасно (вы можете обойтись git pushбез -f).
Даниэль Куллманн
110

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

git fetch && git rebase origin/master

Разрешите любые конфликты, протестируйте свой код, передайте и отправьте новые изменения в удаленную ветку.

                            ~:   For noobs   :~

Следующие шаги могут помочь любому, кто новичок git rebaseи хотел сделать это без хлопот

Шаг 1: Предполагая, что в данный момент в YourBranch нет изменений и изменений, которые необходимо внести. Мы посещаем YourBranch.

git checkout YourBranch
git pull --rebase

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

Шаг 2: Разрешите любые конфликты, которые представляют.

Шаг 3:

git checkout master
git pull --rebase

Что случилось? Извлекает все последние изменения с удаленного мастера и восстанавливает локальный мастер на удаленном мастере. Я всегда держу удаленный мастер в чистоте и готовлюсь к выпуску! И предпочитаю работать только на мастере или филиалах локально. Я рекомендую делать это до тех пор, пока вы не получите руку на изменения или коммиты git. Примечание. Этот шаг не требуется, если вы не обслуживаете локальный мастер, вместо этого вы можете напрямую выбрать и перебазировать удаленный мастер в локальной ветке. Как я уже упоминал в одном шаге в начале.

Шаг 4: Разрешите любые конфликты, которые представляют.

Шаг 5:

git checkout YourBranch
git rebase master

Что случилось? Ребаз на мастера случается

Шаг 6: Решите любые конфликты, если они есть. Используйте git rebase --continueдля продолжения перезагрузки после добавления разрешенных конфликтов. В любое время вы можете использовать, git rebase --abortчтобы прервать ребаз.

Шаг 7:

git push --force-with-lease 

Что случилось? Вносить изменения в ваш удаленный YourBranch. --force-with-leaseбудет проверять, есть ли какие-либо другие входящие изменения для YourBranch от других разработчиков, пока вы перебазируете. Это супер полезно, а не силовой толчок. В случае каких-либо входящих изменений, загрузите их, чтобы обновить локальный YourBranch, прежде чем отправлять изменения.

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

Yahoooo ...! Вы успешно сделали перебазирование.

Вы также можете заняться:

git checkout master
git merge YourBranch

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

                            ~:   (๑ơ ₃ ơ)♥ rebase   :~
bh4r4th
источник
Для чего это: «Извлекает все последние изменения из мастера и перебазирует мастера на последний мастер». Перебазировать мастера на мастера? Разве вам просто не нужно тянуть последний мастер?
Джон Литтл
@JohnLittle Спасибо за указание. Я имею в виду Pulls latest changes from remote master to local master. I always prefer keeping remote master clean and release ready always!. Я обновлю свое описание.
bh4r4th
21

Шаг 1:

git fetch origin

Шаг 2:

git rebase origin/master

Шаг 3: (исправить, если возникнут конфликты)

git add .

Шаг 4:

git rebase --continue

Шаг 5:

git push --force
GauthamManivannan
источник
5
Нет объяснения, с какой ветви начать. Не очень хороший ответ.
Карл Моррисон
12

1. Обновите Мастер первым ...

git checkout [master branch]
git pull [master branch]

2. Теперь перебазируем исходную ветку с главной веткой

git checkout [source branch]
git rebase [master branch]
git pull [source branch] (remote/source branch)
git push [source branch]

Если исходная ветвь еще не существует на удаленном компьютере, выполните:

git push -u origin [source branch]

"и вуаля..."

N Djel Okoye
источник
Мне нравится пошаговая природа этого ответа. Это помогает понять, что именно происходит.
Дэйв Лю
6

git fetch origin master:master тянет последнюю версию мастера, не проверяя ее.

Так что все, что вам нужно, это:

git fetch origin master:master && git rebase master 👌

Naz
источник
Не git fetchобновляет мастер, не проверяя его тоже? За исключением того git fetch, git mergeчто обновления не так ли? Так что, если мы оформим заказ, у masterнего не будет последних обновлений. Так не короче делать в то время как на этой ветке, git fetchто git rebase origin/master? Мы не можем этого сделать, git rebase masterпотому что мы попытаемся сделать ребазинг masterв рабочей области, нам нужно origin/masterполучить информацию из нерешенной, но сидя в локальной сети.
Noitidart