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
