Git and GitHub: Revision Control

Source control is how we try to manage the multiple versions of the code we have: over time, per developer, per feature, per bugfix, per platform, etc.

First, a short video introduction to git:

It is important that you learn basic git from the command line, and also from your IDE of choice. Eclipse, XCode, Visual Studio, Android Studio, etc. they all provide built-in support for git and that is what you should be using on a day-to-day basis. Your normal workflow of commit, push, pull, checkout, and merge/rebase, is fully supported by your IDE. Use it.

Below is a playlist of a few videos I made on using Android Studio with Git and GitHub. The process should be very similar for other Jetbrains products (IntelliJ, WebStorm, etc.)

Initial Workflow

When you are learning git for the first time, I recommend everyone simply use the master branch. Just make sure you frequently commit+pull+push your changes. Many teams do this for the entire first semester (490) as they get comfortable with git.

Recommended Workflow: Named Branches

Once you are comfortable with the basics, I recommend that each team member make (nearly) all changes to a named branch, named after the team member. For example, I would create a branch called jmvidal and make my changes there. The master branch should be reserved only for code that you are ready to share with the team (TIP: share often! like, every day, and pull in the shared changes as often as possible). The specifics commands are:

To create my 'named branch', only need to do this once:

git branch jmvidal

To checkout my branch

git checkout jmvidal

To keep updated on the shared code, do this often

git checkout master
git pull

then, if I want to merge in the shared code (master) into my working branch I do:

git checkout jmvidal
git merge master

When ready to share my code (merge with master)

git checkout master
git pull #this should be a fast-forward merge
git merge jmvidal
git push

To share my branch with others, so they can see what I am doing now

git checkout jmvidal
git push

To pull in my teammate's branch from github to my laptop, the first time I do

git checkout --track origin/his-branch-name

I now have a branch called his-branch-name in my laptop which tracks the same named branch at github. Later on, if he adds more changes to his branch, pushes them, and I want to download them, I just:

git checkout his-branch-name
git pull

The video below demonstrates this workflow, and a few other things, like github pull requests. You have to watch it at 720p to actually be able to read the text.

This named-branch workflow is basically the same as the popular feature-branch workflow except that we create one branch per developer instead of one branch per feature. Most student teams have trouble identifying discrete features to implement (they just start coding, without much of a plan of what they will do) at the beginning. So, feature-branches will not work. Still, by next semester (492) you should start using issues and transitioning to the feature-branch workflow. It is an easy transition.

More advanced git tips

If you are in the middle of something, don't want to commit, but want to pull in the master branch just stash your code and pop it later. Assume that we are in the jmvidal branch, then:

git stash #stash away everything, even my un-committed changes 
git co master
git pull #do what you need to do, then when you are done
git stash pop #bring back my un-committed changes.

You have changed some files but decided all those changes are wrong. You just want everything to go back to where you where on your most recent commit. Simply

git reset --hard

However, if you also added files to your directory that you did not commit, the above will not delete those files. To delete all files in your git directory that are not in your git repo you use

git clean -fd

You did one or more commits that you regret, you want to get rid of them and just go back to a previous time. First find the commit you want to go back to using

git log
commit 87c379822da3bb45e37ac20b633ef75a03b7c92a
...other info
commit c3c0ecc10f968807b8cde449ec64907b79780a02
...other info
commit 5da03e94098a7d59f3586ea07ff7b4276b6fa4f3
...other info
commit 0318d2b5642dc01a359dbdc325e74f24d674634b

to go back to commit 5da03e94 just

git reset --hard 5da03e94

Your current branch and HEAD will now be at 5da03e94. It will be like the other two commits never happened.

Cloning the github wiki

To clone the github wiki git repo (that is, your wiki) locally you just add .wiki in the repo name. For example, if the repo is called demo and you use

git clone

to clone it, then you can clone its wiki using

git clone

To add images, just add them in a new directory and then push. See this stackoverflow question for details.


  • The GitHub Guides have lots of video and text tutorials.
  • The only git GUI that will let you do complex things is SourceTree. Get it. Its free. You probably will not need it, but if things get messed up, it can save you a couple of hours of googling.
  • Udacity has a free online class on How to Use Git and GitHub.
  • Read the Pro Git book. If you read it now, you will save yourself years of misery and depression. Also, you will be able to 'commit' without fear and, thus, pass this class.
  • a fun interactive site.
  • learnGitBranching another interactive site, about branching
  • feature-branch workflow