Note that if you create or checkout master locally, Git typically would create origin/master as the default tracking branch behind the scenes. So, keeping in mind that origin/master is the actual branch which tracks the true remote master branch, we can tell Git to use origin/master as the tracking branch via: # from local master branch Origin/master | local tracking branch for master which mirrors the remote version Origin master | the master branch on the remote (as in the git pull command)
Here is a brief summary: master | the master branch (either local or remote) Then, it does a merge into your local master branch using origin/master.
The first step, git fetch origin, updates the local tracking branch origin/master with the latest changes, such that it mirrors the true master branch on the remote. Whenever you sync with the remote master branch, locally you are actually using origin/master.ĭoing git pull origin master is actually identical to this (assuming you are using the merge strategy by default): git fetch origin It exists mainly to serve as a proxy for the true remote master branch. This is a local branch, which exists on your local repo. Now, for the confusion, there is a third branch called origin/master. Similarly, there is also a branch called master which exists on the remote. The local branch master, which exists only in your local Git repo, is in what you do most of your actual development work. And you should have confusion, because it's confusing.
#GIT SET UPSTREAM HOW TO#
You seem to have some confusion about references in the basic Git commands. by devopscube FebruIn this blog, you will learn everything about setting up an upstream for a git repository, a branch and the -set-upstream-to command usage You will also learn about different scenarios where git upstream is used and how to apply it in your git development workflow.
0 kommentar(er)
