What does "origin master" mean?

Git commands are a leading cause of hair loss for many beginner software engineers, and even for some more experienced ones as well. I've finally realized something that might've helped me when I was first starting out and hopefully will save you some headaches too.

"origin master" explained

At some point in our development career we get real familiar with the classic git push origin master*. What is this command actually saying though? "git push" is pretty clear, but what exactly is "origin master"? For the longest time I thought it meant:

push from your computer to GitHub

I thought origin was my computer, and master was GitHub. To my brain, origin was where the new code I wanted to push had originated (my computer, because that's where I wrote it) and master was where I wanted it to go. Not so far fetched. I was right that they are two separate entities, but I was wrong about which two entities.

Actually, origin refers to the repository on GitHub (aka the "remote repository") where you originally cloned your code from, and master is the branch in origin that you want to push your changes to. They both refer to what's on GitHub.

This cleared up so much for me. Suddenly, in a cascade of insight, other git commands started to make more sense too. It does get more complicated, but hopefully this simple shift in understanding is a stepping stone that will help you have a breakthrough of your own on your way to becoming a git ninja.

*Note: GitHub has changed "master" to "main" so, increasingly, the command will be git push origin main. Older repos will sometimes still use "master". Good to be aware of both.

Comments

[Michael Currin]

Indeed, origin is the remote and the name origin is the default or convention.

after you clone, you can see your remote.

$ git remote
origin

And you can see what it points to. You might use GitHub or BitBucket here.

$ git remote -v
origin  [e-mail]:MichaelCurrin/daylio-csv-parser.git (fetch)
origin  [e-mail]:MichaelCurrin/daylio-csv-parser.git (push)

I guess you could make the fetch and push different but never had to do that.

[Michael Currin]

And if you are working on a fork, it is useful to have two remotes. One is "origin" for your fork. And one is named "upstream" usually and references to the original repo.

$ git remote add upstream [e-mail]:abc/def.git

View

$ git remote
upstream
origin

Verbose

$ git remote -v
# original repo
upstream    [e-mail]:abc/def.git (fetch)
upstream    [e-mail]:abc/def.git (push)
# my fork
origin  [e-mail]:MichaelCurrin/def.git (fetch)
origin  [e-mail]:MichaelCurrin/def.git (push)

Your push and pull operations will use origin by default

git checkout master
git pull # i.e. git pull origin master

git checkout my-feat
git pull # i.e. git pull origin my-feat

git push # i.e. git push origin my-feat

And now you can pull the original repo into your fork!

git checkout master
git pull # origin master
git pull upstream master
git push # origin master

[Michael Currin]

I have notes here if you are interested

michaelcurrin.github.io/dev-cheats...

michaelcurrin.github.io/code-cookb...

[Michael Currin]

If you want git init to start off with main not master, set this in .gitconfig

[init]
defaultBranch = "main"