matyulkov.me

Configuring git to push the current branch

When you’ve just created a local branch and try to push it to the remote you could get the following error:

$ git push 
# fatal: The current branch 00--test has no upstream branch.
# To push the current branch and set the remote as upstream, use
#
#	  git push --set-upstream origin 00--test

To get around it you have to be explicit: please push to this remote, this branch.

$ git push origin 00--test

It’s too wordy even with a simple branch like 00--test, but imagine doing that with feature/ACME-123--add-pagination-to-inventory-list. Autocomplete certainly helps, but you still need to spend some time and effort here.

You could use the command that the error suggests. After you’ve executed it, your local git repo is configured to always push 00--test to origin/00—-test, and you can run simple git push for this branch. You need to do this for every branch though.

$ git push --set-upstream origin 00--test
$ git push # will work now

Would be cool to not have to be explicit.

So, how do we tell git to push the current branch without specifying the remote and the branch name?

Solution: change default push strategy

You can solve this by changing the default push strategy to current.

# repo-level setting, add --global if you want this for all repos
$ git config push.default current

With current strategy git will push the current branch to the remote under the same name. So, given 00--test, git would push it to origin/00-test. This will work for all branches: you just need to make sure you’re actually on the correct branch before you run git push.

Accidents could happen

The current strategy might not work for you if you don’t have the means to prevent accidental pushes to protected branches, or if your git workflow is decentralised with more than one remote.

If you can’t prevent an accidental push to the main branch, then you might accidentally commit and push to it without getting a warning. This could have major implications: you could preview a feature that’s not supposed to go live, you could skip tests and go straight to a prod deployment, etc.

Same arguments work against using this in a decentralised git workflow, with one additional way to mess up: you could push to the wrong remote.

On the other hand, you should be okay with this setting if these conditions are met:

  • your workflow includes pull-requests and feature branches
  • direct pushes to main, develop and other significant branches are disallowed
  • you’re working alone or your entire team is working with the same remote

Other strategies

Push strategies are well-documented on git-scm.com, and there’s one for everyone. The documentation even suggests which strategies are suitable for central or decentralised git workflows. I’ve found several of those strategies particularly curious:

  • simple — the new default as of git@2.0. Pushes the current branch, and warns if it doesn’t exist on the remote.
  • matching — this is the old default, and it pushed all of the local branches to the remote
  • nothing — this requires users to be explicit and just a simple git push without a refspec would never work.