I don’t know if you’ve ever experienced this, but when we switch to a new branch and want to commit code, we always get this error.


Our current branch does not have any upstream branches. Git then prompts us to run the following line of code to set up the remote upstream so that we can push successfully.

Of course, if we execute git push instead of git push, and then add origin, we can push successfully. Like this:


So what’s the reason? What does this origin branch mean? Let’s talk about that today.

Remote branch

A remote branch is actually a branch in a remote repository. For example, if our repO has github, that remote repository is Github, if it has GitLab, that remote repository is GitLab, and the same goes for any other repository.

When using Git Clone, git will automatically name the remote repo origin, pull all of its data, create a pointer to its master, named origin/master, and then create a pointer to the same location locally. I’ll call it master, and I’ll call it remote master.

In other words, origin refers to a remote repository. It’s just a tag, just like the default branch called master, and it doesn’t mean anything by itself. We can come up with other names if we want, but no one does that. For example, with clone we can add -o to alias the remote repO:

git clone -o chengzhi
Copy the code

This way, the remote repo will be named Chengzhi instead of Origin. However, it is not recommended to do so because it is useless except to force and increase the cost.

Operation command

Remember when we introduced Git we talked about the purpose of a remote repO to prevent local code from getting corrupted, so keep a remote copy of it. That way, even if our code dies, we can at least find a backup.

So the greatest use of a remote REPO is to preserve backups, and since backups are to be preserved, our local and remote code interactions are inevitable. Git pull is a remote pull and Git push is a remote push, but you probably don’t know the details. I haven’t talked about remote branches in detail before, so I can’t really go into that, but we’re talking about it today, and it’s a good time to talk about it.

Code to pull

Git pull — Git pull — Git pull However, Git pull is not strictly a code pull command, at least not the most fine-grained, and there is a more fine-grained operation than Git pull. It’s called — Git fetch.

Git fetch is actually a code pull operation that synchronizes remote changes locally. When git fetch origin is executed, origin refers to the name of the remote. If you want to specify more than one remote, you need to add it, otherwise you don’t need to write it. It will pull all remote changes and branches locally and name them origin/ XXX. The origin branch is not visible with git branch. It can only see the local branch name. You can use git branch -r to view the origin branch.

When you use Git checkout to switch over, you don’t have to add Origin. Git automatically generates a local branch pointer to the same node. Git checkout -b test origin/test The difference between Git pull and Git fetch is that both are ostensibly remote changes. Git fetch is for all remote changes, while Git pull is only for the remote branch corresponding to the current branch. Git pull also merges remote changes into a local branch, which means it takes one more step to merge.

Code push

When it comes to code push, we return to the question at the beginning. When is git push ok, and when does origin need to be added?

One mechanism involved here is that local branches do not automatically synchronize with remote branches. For example, someone on the remote branch creates a test branch and we call it Origin /test when we pull it to the local branch. We could also create a test branch of our own and stay on top of it. This is also for convenience, as there may be potential conflicts if name mappings are used directly. And since there can be multiple remote REPOs, we have multiple options when we push.

The most complete push command would look like this:

git push origin test:cz/test
Copy the code

We notice that we use the odd notation test:cz/test, which means that the local test branch is pushed to the remote as the CZ /test branch. If we want the local name to be the same as the remote name, we can omit the shorthand: git push origin test.

If you set the upstream of the current test branch to be a remote test, or if the local test is copied from Origin, then you can directly git push it, and it will automatically associate the local branch with the remote branch. In fact, this is how most of our push operations work. To map a local branch to a remote branch, use this command:

git branch --set-upstream-to master origin/master
Copy the code

It represents the local master and master of the remote connection, after setting associated we only need to git push and git pull can update and push the branch, is more convenient.

There are some things about remote branches that we haven’t covered, such as how to track remote branches, how to delete them, and so on. Since these are so rarely needed that we will forget them even if we try to memorize them, we won’t repeat them.

That’s all for today’s article. I sincerely wish you all a fruitful day. If you still like today’s content, please join us in a three-way support.

Original link, ask a concern

This article is formatted using MDNICE

– END –