3

My question is around how branch pushes work exactly; I have come across something that doesn't make logical sense to me and as such would like an explanation as to why I am experiencing this behaviour.

I have two branches: master and dashboard.

I am on (checked out) dashboard. I make some changes on it and (using the terminal) I type the following:

git add file1.R
git commit -m "Updated loop."
git push origin dashboard

My understanding is that this now pushes the committed changes into my repository under the dashboard branch.

However, out of curiosity I also tried this (whilst still checked out on dashboard:

git add file1.R
git commit -m "Updated loop."
git push origin master

Despite specifying that I want to push to master, the committed changes still appear to have been pushed to dashboard because when I check master (both via a GUI and git log -1), I see that the changes haven't been pushed to master, but rather to dashboard.

As such, what is the relevance of specifying which branch to push to? The reason I ask is because it appears that the branch that the committed changes are pushed to correspond with whichever branch I currently have checked out / am pushing from.

Would git push be the same as typing git push origin master/git push origin dashboard (depending on which branch I have checked out)?

It would be great to understand precisely what is happening here.

7

I have glossed over some stuff to stay straight-forward. Check man git help for the nitty-gritty.

git push on its own says "push my current branch to its corresponding upstream branch".

git push origin xyz says "push my xyz branch to it's corresponding branch in origin". It does not say "push my current branch to origin's xyz, though that's a very easy assumption to make.

To do what you thought you were doing, use something like git push origin dashboard:master ("push my dashboard branch to master in origin"). This is safe in the sense that it will only work if the branch you are pushing is up-to-date with the branch you are pushing to, so that you will not lose history.

git push is quite flexible (again, see the manual for details), but the pertinent parts can be summarized as:

git push [remote [source][:destination]]

That is, if you specify a remote (such as origin) you can specify a source (local) to push from, and a destination branch (on the remote) to push to.

  • With neither source nor destination, it will push the current branch to its corresponding upstream branch.
  • With only a source, it will push that branch to its corresponding upstream branch.
  • With only a destination, it will "push nothing" to that branch - which means deleting it on the remote.
  • With both, you can push a local branch to one which is not its default corresponding one.
  • Source does not have to be a branch - it can be HEAD ("current branch"), master~1 ("previous commit on master), etc..
  • 1
    So according to your explanation (and also my experience/expectation) MusTheDataGuy simply made a wrong observation? – gillesB Nov 22 '18 at 7:07
  • 2
    @gillesB I can only guess, but it looks like the file was already comitted and pushed to dashboard when Mus started experimenting. Personally I usually gloss over git's feedback messages unless they are longer than one line, so it would be easy to miss, for example, "No staged changes" and "Everything up to date" when adding an unchanged file, comitting an unchanged index, and pushing an unchanged branch. – Jacob Raihle Nov 22 '18 at 10:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.