Push branch merge to Github

Question

I have a master and a test branch both locally and synced with my Github account. I've merged the test branch into master since I'm done with it:

git checkout master
git merge test

Now I want to push this merging to Github and I don't know which one of these three commands:

git push
git push origin
git push origin master

I should use. Which is the correct one and what do they do different?

Answer 1

If you do not specify in git push the remote or the branch, it will take by default origin The second part is a more complex and depends on the git configuration that you have. The different behaviour depending on the push.default option that you have in the git configuration, will behave in one way or another. These are the possible values of push.default and how will git push behave:

nothing - do not push anything (error out) unless a refspec is explicitly given. This is primarily meant for people who want to avoid mistakes by always being explicit.

current - push the current branch to update a branch with the same name on the receiving end. Works in both central and non-central workflows.

upstream - push the current branch back to the branch whose changes are usually integrated into the current branch (which is called @{upstream}). This mode only makes sense if you are pushing to the same repository you would normally pull from (ie central workflow).

simple - in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch's name is different from the local one.

When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners.

This mode will become the default in Git 2.0.

matching - push all branches having the same name on both ends. This makes the repository you are pushing to remember the set of branches that will be pushed out (eg if you always push maint and master there and no other branches, the repository you push to will have these two branches, and your local maint and master will be pushed there).

To use this mode effectively, you have to make sure all the branches you would push out are ready to be pushed out before running git push, as the whole point of this mode is to allow you to push all of the branches in one go. If you usually finish work on only one branch and push out the result, while other branches are unfinished, this mode is not for you. Also this mode is not suitable for pushing into a shared central repository, as other people may add new branches there, or update the tip of existing branches outside your control.

This is currently the default, but Git 2.0 will change the default to simple.

Source:

• http://git-scm.com/docs/git-push
• http://git-scm.com/docs/git-config (and search for push.default )

Answer 2

They differ in how much information you are giving Git right in your command, and how much Git must fill in from your configuration, falling back to Git's default settings. The exact behaviour may also depend on your version of Git.

In many repositories, these three commands would behave the same way.

Here is what the documentation for git-push says from my version of Git (1.8.3.2):

When the command line does not specify where to push with the
<repository> argument, branch.*.remote configuration for the current
branch is consulted to determine where to push. If the configuration is
missing, it defaults to origin.

So, if you've got a branch.master.remote set, that's what Git will use. If not, it falls back to origin . If you created your local copy by clone ing, this is likely already set. Similarly, if you have done something like git push -u origin master , this should be set.

You can verify by running git config branch.master.remote , which should output something like origin .

More from the documentation:

When the command line does not specify what to push with <refspec>...
arguments or --all, --mirror, --tags options, the command finds the
default <refspec> by consulting remote.*.push configuration, and if it
is not found, honors push.default configuration to decide what to push
(See gitlink:git-config[1] for the meaning of push.default).

Similarly, if you've got remote.master.push set, that's what it will use. And again, if you've done git clone or git push -u ... this is likely set.

Verify it with git config branch.master.merge , which should output something like refs/heads/master .