Как «вытащить» из местного филиала в другой?

231

Это звучит так просто, но я просто не могу понять это. Я сделал экспериментальную ветвь некоторое время назад, и теперь я хотел бы внести все изменения, которые произошли на master, так как я сделал это. Это все местное. Я хочу вытащить из локального мастера в локальный my_branch, но я не могу это сделать. Кажется, это не работает, говоря мне, что master - это не git-репозиторий:

git pull master

git

— Фил Кулак
источник

См. Также stackoverflow.com/questions/3124601/…

— Майкл

339

вы должны указать git, откуда вытащить, в данном случае из текущего каталога / репозитория:

git pull . master

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

git merge master

— knittl
источник

1

Мне нравится, git pull . masterпотому что я думаю, что он также проверит, есть ли что-то новое от происхождения. Это правда?

— Джозия Йодер

1

@JosiahYoder no, в pull .частности, говорит Git извлечь из репозитория, расположенного в .(то есть из текущего каталога / репозитория). originэто просто сокращение для "любого местоположения хранилища, определенного в .git/configфайле (обычно устанавливается автоматически при клонировании хранилища)

— knittl

1

Ой! Так git pull . masterбудет ли тянуть из локального хранилища вместо источника? (Никаких извлечений из происхождения !?) Есть ли преимущество git pull . masterперед этим git merge master?

— Джозия Йодер

2

@JosiahYoder да, точно, он "вытянет" из локального хранилища вместо исходного хранилища. Выборка не производится (потому что все из локального репозитория уже здесь!). Там нет никакого преимущества - обе команды делают более или менее одинаково. Если вы делаете перемотки вперед, вы можете использовать push . origin/branch:branch(не тянуть) для обновления локальных ветвей, не проверяя их в первую очередь.

— Knittl

Я восхваляю тебя. Силой Грейскулла!

— Р Клавен

45

То, что вы ищете, сливается.

git merge master

С pullвами можно получить изменения из удаленного хранилища и объединить их с текущей веткой.

— KingCrunch
источник

38

Довольно старый пост, но он может помочь кому-то новому в git.

Я пойду с

git rebase master

намного более чистая история логов и отсутствие слияний (если все сделано правильно)
Нужно иметь дело с конфликтами, но это не так сложно.

— Лукино
источник

1

у команды разработчиков, конечно, есть много способов управлять своими ветвящимися процессами. Лично я использую git уже 8 лет, и мне никогда не приходилось перебазировать. Я всегда использую слияние, и оно всегда отвечало моим потребностям. Конечно, с rebase, как и слияние, могут возникнуть сценарии, когда git не может автоматически определить правильный результат «слияния» двух наборов изменений. Относительно того, что вы высказали в отношении «более чистой» истории коммитов Лично я предпочитаю поддерживать всю историю коммитов, на всякий случай, если мне когда-нибудь понадобится выполнить некоторую «археологию коммитов» (как это часто случается!)

— user3441604

-1

Если вы ищете новый инструмент из другого филиала, например, из местного в мастерский, вы можете следовать этому.

git commit -m "Initial Commit"
git add .
git pull --rebase git_url
git push origin master

— theRana
источник