I'm using a repository which exists both on github and on an internal gitlab.
I have set up two remotes: origin
(github) and gitlab
.
How can I easily interact with the branch master
of both remotes?
What I've tried:
git checkout --track gitlab/master
-> error: A branch named 'master' already exists.
git checkout -b master-gitlab --track gitlab/master
-> worked, I now have a local branch master-gitlab
and the console output tells me: master-gitlab set up to track remote branch master from gitlab.
-> perfect, this is what I want!git push gitlab master-gitlab
-> this creates a new remote branch master-gitlab
on remote gitlab
which is not what I want and inconsistent with the output of the last command.git push gitlab master-gitlab:master
which pushes master-gitlab
to master
of the remote gitlab
. But I always forget how to do this and it's not very intuitive.Is there an easier way to track the master
branch of a different remote and push to it?
Is this a git-bug that it first (3) is telling me tracking master
and afterwards creating a new branch on push?
It's not a bug in the sense that git is doing what the documentation says it will do. It also may not be the most intuitive result in this case, but with how many different ways there are to relate remote branches to local refs I don't really think there is a behavior that will be intuitive to everyone in every situation.
In general, push configuration is set separately from pull configuration. (You can see the git push
documentation for a rundown of how it tries to figure out what to push where when you don't specify everything on the command line. https://git-scm.com/docs/git-push)
That said, the default push configuration does try to use the pull configuration if you are pushing to the default remote. You can configure push
to always default to upstream configuration with
git config push.default upstream
Then you can push master-gitlab
using just
git push
if it's checked out, and
git push gitlab master-gitlab
in any case. Of course since this changes a default setting, it could potentially affect your other interactions with gitlab, so I'd encourage you to review the docs and make sure you understand the differences in behavior to decide if it's worth it.