Git and GitHub: Introduction, setup, and our workflow

Git and GitHub are going to be two incredibly important systems that we will be working with at every stage of development, so we need to take some time to learn how to use them properly. This post will cover a brief introduction to each, a tutorial for setting up Git on your local machine, and a workflow that we can use during development.

Introduction

Git

Git is version control system that was developed for managing the Linux source code. What sets it apart from some of the other popular forms of version control (such as Subversion and CVS) is that it was designed as a distributed system, instead of a more traditional client-server setup in which developers connect frequently to a central repository to make and view changes. This distributed setup has a few key advantages:

1. It's faster. Networks can be slow or unavailable, which slow down development time. With Git, a complete copy of the entire repository is stored on each client's machine, allowing the entire project history to be viewed extremely fast, even if there is no network connection. It's also faster to switch between different branches of development within a project.
2. It's safer. Since a complete copy of the entire repository is stored with each client, the risk of losing the entire project due to a disaster (hard drive crash, fire, alien invasion) is much, much smaller. Contrast this with a non-distributed system, where problems with the central repository can cost hours, days, or weeks of development time to be lost if something bad happens.
3. It's flexible. Git doesn't dictate what kind of workflow you use. There are a variety of different strategies for branching, merging, and promoting changes that are possible and it comes down to picking the one that's best for your team.

GitHub

GitHub is one of the most popular places for hosting a publicly available Git repository. They provide a nice web interface for browsing and cloning projects, as well as managing tasks and documentation related to the project. Private repositories are also available to restrict access to the project.

Setting up Git

Setting up Git for the first time can be a bit of a challenge, especially on Windows, but here are some guidelines.

Windows

Unfortunately I don't have a Windows machine to walk through the steps on right now. I lied. I do, I'm just lazy. Fortunately for us, GitHub already has a really great guide for getting setup on Windows.

Mac OSX

Git should come installed with OSX, but you can double check by opening up a terminal and trying the following commands.

The commands 'which git' will show you were Git is installed and 'git --version' will show you what version is currently installed.

Like Windows, we'll need to setup a set of public-private keys. The keys are necessary for communication between your machine and GitHub. GitHub already has a really nice step-by-step guide here, so I won't bother repeating it.

Now what?

If you've made it through your respective GitHub tutorial, it's time to setup a client. This step is not strictly necessary (you can stick with the command line if you want), but finding a nice client can make your life much easier.

For Mac, I will be using a client developed by GitHub called GitHub for Mac. I have very limited experience with it but it offers some pretty tight integration with GitHub that I think will be valuable. You may want to look for an Eclipse plugin instead but I'm not familiar with the options available.

The Workflow

I'd like to try using a workflow similar to the one posted by Scott Chacon in which he describes the process they use during the development of GitHub itself called GitHub Flow. Side note: I realize this post is starting to sound like I'm a huge GitHub fanboy. I didn't realize it until now, but I guess it's true. Anyways... I highly recommend that you read this article. At this point it's not important to understand the Git-specific terminology (push, pull, merge, branch, etc). Rather, focus on the core points of the flow:

• Anything in the master branch is deployable/demo-able
• This will ensure that we have one branch that is always ready to be deployed to a phone and demoed - even if there is significant development going on around it. This will reduce the risk of our project tremendously.
• Create descriptive branches off of master during feature work
• This will help narrow down our focus during development. For example, branches such as map-controls, creep-walk, or hud-menu will be created, developed, and then merged into the master branch once they are stable and reviewed.
• Push to branches on the server constantly
• So valuable! Since we will have a bunch of fairly narrow branches in different states of development, we can push changes to the GitHub without worrying about disrupting the work of others (since they'll most likely be on different branches). This will help keep track of progress, and also allow for better discussions when problems are encountered, since it's trivial for anyone to switch over to another branch to view and/or develop.
• Using 'pull requests' for code review and branch merge coordination
• This will be good because it will provide a good way to share the changes that are going on in the system, keeping everyone in the loop.

So that's all for now. I want to run through a live demo of development on a mock project during our Tuesday meeting, so please make sure you have Git setup on your machine and are ready to go!