In this brief post we’ll cover the terms “origin”, “remote” and work with pulling & pushing from externally hosted repositories.
If someone were to break into your house, rip your PC from the wall and throw it into the ocean, you’d never get your code back, unless it was hosted “in the cloud” or on another server. That’s part of why Github & Bitbucket exist.
Github acts as a central repository that all developers on a project can get the most recent code from. You’ll also probably have another server where your code is running in production, think Heroku, Firebase, or DigitalOcean.
So, what is Origin in Git?
Origin is an “alias” on your system for a particular remote repository. Say you make some changes to a project on your local system, and you want to push it up to Github. And you want to push it to production (Heroku), and you want to push it to your staging server. You could push to each of the three “remote repositories” by using the alias assigned to each repository. Here’s an example:
$ git push origin master #most likely pushing to github. "origin" is commonly used to refer to github/bitbucket etc... $ git push heroku master # Pushing code to your production server (which is heroku in this case) $ git push staging master # pushing code to a staging server.
Let’s actually give it a shot with Github. Proceed with the following steps:
- Create a project directory
$ mkdir remotesTest
$ cd remotesTest
- Create project file:
$ echo "hello world project" > file.txt
- initialize repo:
$ git init
$ git add .
$ git commit -m "initial commit"
Now we’re ready to push this local repository to our “remote” repository off our local machine (Github). Go to Github.com, log in, and in the top left click “new”
Name the repository and click “create repository”
Now you’ll see that it gives instructions (see below image)… But you don’t have to use “origin” like they tell you to.. It’s just the standard so it makes sense… but let’s name our origin “kitten” just to see that we can.
Follow the steps below: Just be sure to use YOUR url, and not mine…
$ git remote add kitten https://github.com/truthseekers/remotesTest.git
$ git push -u kitten master
Now refresh the github page and you’ll see the github repository hosting your code. “Origin” is just a label on your local machine that identifies a remote repository. In our case we named the “github remote” kitten. So now if you wanted to launch your code and use Heroku… you could create a new alias for each “remote repository”.
You can list out the available “branches” and “remotes” with either
$ git branch
$ git branch -r or
$ git branch -a
This is where we would see all the “remote branches” that this repository is connected to on our local machine. Github, staging server, production server, etc….
Now let’s delete the repository off our local computer, and do a git clone from the Github repository. Refresh your Github repo page and click the green clone button. Copy, and paste into your terminal:
My command will end up looking like this:
$ git clone https://github.com/truthseekers/remotesTest.git
Now if you run git branch -a again you’ll see the remote has the standard “origin” name. I personally never rename my origins. I just have one for staging, one for production, and one for Github and call it good. So now if we wanted to push code to Github, we’d use the command
$ git push origin master
Git pull retrieves the latest changes in the repository and “pulls” them into your local machine. If you’re working on a project with multiple people, they’ll push changes up to the Github repository and then the code you’re working with becomes out of date. you pull changes to keep your project up to date. “git pull” is running two commands in one. It runs
$ git fetch which downloads the most recent remote changes, and then runs
$ git merge which we talked about in a previous post.
Let’s test it out by following the steps below:
Make a change with Github’s UI to the file.txt. Click the file to edit.
Edit the button, make a commit message, and click “commit changes”
Now our “local repository” is out of date because it doesn’t have those changes that we just made to the file. Use git pull to get the most recent updates.
$ git pull
And now our repository is up to date again! In a real world use case you may have conflicts that need to be resolved. If you weren’t aware of recent changes and attempted to push your changes to the remote repository, you’d end up with an error that looks like this:
You would then know that you need to pull the most recent changes into your repository, and THEN push your changes up to the remote repository. Some people like to use git fetch, and then use git checkout to view the changes before running git pull, but for me, if there’s changes that I can’t handle then i’ll just run
$ git merge --abort to abandon the merge.