A basic intro to Git and Github

Git is a system for making backups of source code.  It allows you to atomize each change you make to the code which can then be rolled back independently of later changes.  Github is a website which people can publish their code which is tracked in git to.  It allows for easy collaboration between multiple people on single projects.

I've wanted to learn more about Git for a while, since it is the trendy version control system.  However, it has a notoriously steep learning curve.  As such, there are many overviews available online.  In keeping with the general theme of this blog I've decided to provide my own inferior overview.

As I said, there are many guides online, but I liked this one.

The main thing I want to summarize is the different conceptual levels a file goes through in the backup process:

• To begin, we have untracked files.  All your files will begin at this level, and git will do nothing with them until you tell it to.


• The first time you add a file, it becomes tracked.  This means git will monitor it and when you run git status, it will alert you to changes.


• You must explicitly stage files which are part of a single change.  Files that are staged will all by saved by the next step.  You stage files with git add.


• When you commit changes it takes the currently staged files and makes a record of the changes.  At this point the changes are backed up locally, and you can roll them back later.  You can skip the staged step and directly commit any tracked file that has changed with git commit -a.


• For remote backups, you can push your changes to a site like Github.  Once the files are uploaded there, others can see them and download them with pull.

This is the basic gist of using git as a single user backup system.  If you want to collaborate on files that's when things like branches and merges become more useful.