We will learn how to work with remote repositories in detail in the collaborative distributed version control lesson.
In this section we only want to get a taste to prepare us for other lessons where we will employ GitHub.
Our goal is to publish our guacamole recipe on the web. Don’t worry, you will be able to remove it afterwards.
We have seen that creating Git repositories and moving them around is simple and that is great.
So far everything was local and all snapshots, branches, and tags are saved under .git
.
If we remove .git
, we remove all Git history of a project.
To store your git data on another server, you use remotes. A remote is treated the same as a branch - most of the same concept apply, but you can also push changes to the remote and pull from the remote.
You might use remotes to:
There are different types of remotes:
One option to host your repository on the web is GitHub.
GitHub is a for-profit service that hosts remote git repositories for you. It offers a nice HTML user interface to browse the repositories and handles many things very nicely.
It is free for public projects and hosting private projects costs a monthly fee (but educational discounts exist). The free part of the service has made it very popular with many open source providers.
CodeRefinery does not in any way endorse the use of GitHub. There are many commercial and open-source alternatives, just check the list above. In the end, it is a balance between control and visibility, and we use GitHub because you are likely to have to use it for other software anyway.
By now you should already have set up a GitHub account but if you haven’t, please do so here. But it is OK if you want to use GitLab or Bitbucket or NotABug or another platform instead (although we will practice collaborative Git on GitHub tomorrow).
On this page choose a project name (screenshot).
For the sake of this exercise do not select “Initialize this repository with a README” (what will happen if you do?).
Once you click the green “Create repository”, you will see a page similar to:
What this means is that we have now an empty project with either an HTTPS or an SSH address: click on the HTTPS and SSH buttons to see what happens.
To push changes to the project you will either need SSH keys for the SSH address (preferred) or you will have to use your GitHub username and password when using the HTTPS address. If you don’t know what to do, use HTTPS.
We now want to try the second option that GitHub suggests:
… or push an existing repository from the command line
git status
.$ git remote add origin https://github.com/user/recipe.git
$ git push -u origin master
You should now see:
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 259.80 KiB | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
To github.com:bast/recipe.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.
Reload your GitHub project website and - taa-daa - your commits should now be online!
What just happened? Think of publishing a repository as uploading the .git
part online.
Now other people can clone this repository and contribute changes. In the collaborative distributed version control lesson we will learn how this works.
At this point only a brief demo - if you copy the SSH or HTTPS address, you can clone repositories like this (again adapt the “namespace/repository.git” part):
$ git clone https://github.com/user/recipe.git
This creates a directory called “recipe” unless it already exists. You can also specify the target directory on your computer:
$ git clone https://github.com/user/recipe.git myrecipe
What just happened? Think of cloning as downloading the .git
part to your
computer. After downloading the .git
part the branch pointed to by HEAD is
automatically checked out.
A repository can have one or multiple remotes (we will revisit these later).
Local branches often track remote branches.
All this might be a bit nebulous but we will add clarity later this week.
A remote serves as a full backup of your work.
We’ll properly learn how to use these in the next “git collaborative” lesson.