Git (and GitHub) Cheat Sheet
I wrote a very simple, very basic introduction after I showed my lab some of the basics of version control (git — in the most simple terms, it is a system to keep track of your code) and a website providing such services (GitHub). It is meant to be a cheat sheet mnemonic with extra information to help remind them what each of the very basic commands I showed them does. Twitter showed extreme appreciation for it — perhaps because many tutorials go a bit like this — so maybe it is useful to a wider audience of newbies not just my lab. Two main assumptions I make are that the reader is interested in maintaining their code and knows what a terminal is, as all the following commands are meant to be typed into a *nix terminal. See this for a tutorial on how to use the command line.
Create a New Repo
To create a new repository on GitHub go to: https://github.com/new
Get Unlimited Private Repositories
Sign up for the academic/student pack on GitHub as many lab projects (also known as repositories or repos) might need to be private (until publication, of course) and non-academics do not get unlimited free private ones. Sign up here — they only need your academic (.ac.uk or .edu, etc.) email address to associate it with your account.
git clone firstname.lastname@example.org:oliviaguest/gini.git
This command makes a new directory called in this case:
gini. So you would need to change directory in order to see your newly downloaded files, i.e.,
cd, like so:
Then you can
ls -a to see all your files.
Feel free to actually
clone my Gini repository as you cannot break it on GitHub since you do not have
Adding a file means asking version control to start watching it, but it is not yet in the history of your repository.
Just adding is not enough! All
add does is say add this file to queue of files to be
committed (the next section). You can be explicit and name the files you want to add (all other files will not be added):
git add filename_1 filename_2... filename_n
Alternatively, you can add everything (except the things in your
git add -A
If you just
add a file, it is not safe yet!
It needs to be
committed (next section) to be safely under version control!
Committing is adding all the files to version control, although not to the server (the next section).
To commit everything you have just
git commit -m "I've just made some very dramatic changes"
For your files to be 100% safe make you must also
push them (the next section).
committing makes files be under version control on your local machine, e.g., your laptop, but they will not be accessible from another computer.
commits, and therefore files, makes your changes enter into the version control system on the server as well as your local machine, so on GitHub (or Overleaf, or GitLab, or whatever server you are using).
So pushing is the superior form of backup and version control because it means that there are at least two copies of your work and its history: one local copy (the stuff you were just working on) and one server-side copy (what you just
Once everything you need is
committed, it is time to
adds may be in one
commits may be in one
But there is no reason to limit yourself to pushing once a day.
Push as often as possible pretty much, is my advice.
Unsurprisingly, as you might guess, to
push you type:
Check the Status
To check what is going on, what changes have been made, compare your local repository's status with that of the server, etc., type:
This command will often tell you what you need to do given the current changes you have made, e.g., tell you you need to
If you are unsure of anything, running
git status should give you a hint about what the next command you want to run is.
Importantly, if you have made server-side changes, i.e., you did some work on machine A and
pushed all that work to the server and now you are on a completely different machine B and need to get back to working on your repo, you need to tell the repo on this different machine B to check the server for changes.
This can be done by asking your local git, on B, to fetch the changes from the server:
Bear in mind that
fetch does not download any files, it merely updates what your local git knows about the changes you did on machine A which you then
pushed to the server.
fetching, you may run
git status as then the information on the differences between your local files and those on the server will be correct.
Otherwise, if you just run
git status you risk getting the wrong information about what is on the server versus your local repo.
If you made some local changes and you do not want them around at all — you just want what is on the server, you can run:
This discards all your local changes that have not been
Pulling means getting stuff from the server. If you have made changes at work and then go home and want to continue working where you left off, you run:
pull does the opposite of what
push does. It downloads all the files you previously pushed to the server from work on your home computer.