For example, I'm now in develop
branch, and want to pull remote master to local master, what I do is:
$ git stash
$ git checkout master
$ git pull
$ git checkout develop
$ git merge master
Question 1: How to pull remote master to local master when I in develop
branch?
Question 2: Is it possible to merge remote master to local develop in one command? currently I use 4 commands
Answer-1: Your working procedure is ok for question-1
.
$ git fetch
$ git stash
$ git checkout master
$ git pull origin master
$ git checkout develop
$ git stash apply
Answer-2: You can pull origin/master
into your local develop
branch directly.
$ git pull origin master
There are already other good answers to your question 2 (see sajib's). The short answer to question 1 is, "You can't".
However, If I can rephrase your question slightly to: "How can I pull remote master onto master while keeping develop checked out?" then you can use git worktree
to your advantage. It gives you another working tree to do all the normal things you'd do with a working tree.
If you're on the develop branch and want to update master, for example:
git worktree add ../second-repo master
git -C ../second-repo merge origin master
Now master has been updated in your local repo.
To explain the above commands, git worktree
will checkout master into another folder ( ../second-repo
). The second command will execute git merge origin master
only after virtually changing directories to the new worktree. Note that once you have a worktree set up, there's no need set it up again. You can just keep using the same worktree to update master.
You're doing two merges there, one from origin/master
to master
, the second from master
to develop
, and you're doing them starting from a dirty worktree.
Merges need a worktree for conflict resolution: if origin/master
and master
both change a file, git has to do some work with the content, merging any that don't affect overlapping regions and possibly punting ones that do to you for your own inspection.
Usually , the sequence you show above can run without human intervention, but the important thing to stay aware of is that, at every step (and also the git stash pop
you didn't show), it's very possible that somebody's going to have to look at a merge conflict and decide what was really meant.
Here's the example I usually give: suppose you change
if ( tag == mark
|| tag == error ) {
to
if ( g->tag == mark
|| g->tag == error ) {
and someone else changes it to
if ( tag == mark
|| tag == error
|| tag == release ) {
what is git supposed to do? I contend it does the only thing sanely possible: it punts, and asks you to decide what the result should look like. Anyone familiar with C-family languages will be all but certain that the correct resolution is
if ( g->tag == mark
|| g->tag == error
|| g->tag == release ) {
but arriving at that only when it really is the correct resolution is not within the generally accepted limits of reasonable expectation.
Answer-1: fetch first from remote and then force branch...
$ git fetch
$ git branch -f master origin/master
You can also just put origin
without /master
as it will default to it!
You can "jump" to the forced branch by replacing branch -f
with checkout -B
like this...
$ git fetch $ git checkout -B master origin/master
Answer-2: just pull (fetch & rebase/merge in one) defining the remote and branch...
$ git pull origin master
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.