Am I understanding correctly about git push and git pull?

Question

For example, I have these branches:

local                remote
master         ->    origin/master   (other users will update)
develop        ->    origin/develop  (other users will update)

And as of now, master/develop are pointing to same commit

Say I only have a README file and its content is master

1, I do following

$ git checkout develop
$ echo 'develop' >> README && git commit -am 'aaa'

Question: Suppose no other one changes origin/develop, no matter which branch I am in, git push origin develop will push local develop to origin/develop ?

2, After 1, become this:

local                       remote
master (README: master)     -> origin/master (README: master)
develop(README: develop)    -> origin/develop  (README: develop)

Next, someone changed origin/develop:README to other develop

local                       remote
master (README: master)     -> origin/master (README: master)
develop(README: develop)    -> origin/develop  (README: other develop)

So if I do

A. [in develop branch] $ git pull origin develop

my local develop:README will become other develop

B. [in master branch] $ git pull origin develop

my local develop:README will not change but my local master:README will become other develop???

so git pull origin develop does not mean pull origin/develop to local/develop?

It means pull origin/develop and merge into current branch ????

So how to pull origin/develop to local develop when I am in other branch?

git pull will update local master to origin/master and local develop to origin/develop, is that right?

Be careful with terminology. `origin/develop` is *your* Git's "remote-tracking branch", and not a branch on the other Git. But `develop` is your branch when used with your Git, and when your Git phones up another Git over the Internet-phone (for fetch and push), *they also* have a local branch `develop`. Your `origin/develop` is just your Git's *memory* of their `develop`, from the last time your Git talked with their Git. — torek, Jan 19 '17 at 06:08
My answer [here](http://stackoverflow.com/questions/20106712/what-are-the-differences-between-git-remote-prune-git-prune-git-fetch-prune/#answer-20107184) may help to answer some of your questions. @torek is absolutely right though: there are essentially three views (local, your remote snapshot, and what is actually on the remote). — John Szakmeister, Jan 19 '17 at 09:02

Antony Hatchkins · Accepted Answer · 2017-01-19T08:54:07.063

1

no matter which branch I am in, git push origin develop will push local develop to origin/develop ?

Right.

So how to pull origin/develop to local develop when I am in other branch?

git pull = git fetch + git merge

You can git fetch - this will fetch all changes from the remore repo to your local tracking branches (eg origin/master, origin/develop).

But you cannot git merge into a noncurrent branch because during merge conflicts may arrise and you won't be able to fix them unless the branch is current.

If you are working on master and you want to set your work aside, merge develop branch and then continue your work on master, you can do the following:

git stash
git co develop
git pull
<resolve conflicts if any>
git ci
git co master
git stash apply

where ci=commit, co=checkout.

git pull will update local master to origin/master and local develop to origin/develop, is that right?

It will fetch both, but merge only the current branch.

Update: As an illustration to @torek's comment to the question, here's a more precise scheme. Actually there're more branches than you've drawn:

                 local repo                                      remote repo
local branch            remote tracking branch             local branch            
master (README: master) origin/master (README: master) <-> master (README: master)
devel (README: devel)   origin/devel (README: devel)   <-> devel (README: devel)

Usually the centeral repo ('remote repo' in this scheme) is created without a working tree (git init --bare) so it doesn't have remote branches, only local ones.

Now

git push:

              local repo                                      remote repo
local branch            remote tracking branch             local branch          
master (README: master) ---------------------------------> master (README: master)

git fetch:

                        origin/master (README: master) <-- master (README: master)

git merge:

master (README: master)<-origin/master (README: master)

and finally, git pull = git fetch + git merge

edited Jan 19 '17 at 08:54

answered Jan 19 '17 at 04:12

Antony Hatchkins

31,947
10
111
111

`git pull` will pull everything, right? even other's branch which will be merged and deleted soon, so when I do `git branch -va` will end up with many branches I don't need, basic I only need to `git pull remote/master to local/master` – Sato Jan 19 '17 at 04:27
Yes, `git pull` fetches all branches. You can either (1) agree with your team not to push temporary branches to the central repo (there's a setting to aid in it - eg `git config push.default=current`), (2) fetch only the branches you need (always `git pull master` instead of `git pull`) or (3) agree to include user name into the name of the branch, eg "sato-refactoring" to avoid the mess. – Antony Hatchkins Jan 19 '17 at 04:42
so what is the difference between `git pull origin master` and `git pull master` ? – Sato Jan 19 '17 at 04:49
`git pull master` : fatal: 'master' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. – Sato Jan 19 '17 at 04:51
I meant `git pull origin master`. – Antony Hatchkins Jan 19 '17 at 04:53
`git pull` actually *doesn't* fetch all branches: it runs `git fetch` in a restricted mode that fetches just the requested branch (or branches—but normally just one branch). If you run `git fetch` manually, that *does* fetch all branches. So it's better to use `git fetch`, after which you have everything from `origin` and can merge or rebase multiple branches without having to fetch again. (Or, shorter version: avoid `git pull`. It's meant as a convenience shortcut, and yet, it's actually *inconvenient*.) – torek Jan 19 '17 at 06:11
@torek `git pull` without arguments fetches *all* branches. You can try yourself. What it actually does is it fetches all branches listed in the `[remote "origin"]` `fetch` section of `.git/config`, which is usually +refs/heads/*:refs/remotes/origin/*. Both `git pull` without arguments and `git fetch` without arguments fetch exactly the same branches into the same place. When there's a branch(es) listed as arguments to `git pull` (or `git fetch`) they both fetch just the requested branch(es). – Antony Hatchkins Jan 19 '17 at 08:23
Yet I also prefer `git fetch` over `git pull` and advise everybody to use it. – Antony Hatchkins Jan 19 '17 at 08:24
Ah, right, even the old script version says `git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1`: it passes no remote nor branch (`$@` is empty) if you did not write, e.g., `origin master`, and only limits the fetch when you do provide both remote and branch. (I avoid `git pull` enough to have forgotten this!) – torek Jan 19 '17 at 08:58
@torek Yeah, I tend to avoid `git pull` as well, so I had to test it to make sure that it really works this way. – Antony Hatchkins Jan 19 '17 at 09:46

Am I understanding correctly about git push and git pull?

1 Answers1