Fri 1 Apr 2011
Gitastrophe – Part 1
Posted by Aaron under Rant, Web, Work
No Comments
Yes it may seem like when you switch over to a new revision system, git perhaps? That your brain may explode. Or that things might turn into a major catastrophe. Be that as it may I'm going to let you in on how I get things done at my job using git in my daily workflow. This is by no means the best way to get things done, or the end all solution... so comments and suggestions are very welcome.
So at my current place of employment we have 4 developers coding out of the same code base. It would seem like it would be easy enough to not step on eachother's toes, but it happens. Sometimes it happens a lot! Some of the main reasons:
- Whitespace in code
- Large files/classes/controllers (multiple people working out of the same file)
- Unique workflows
- Different programming environments
- Improper merges
I could go on for at least another minute or two, but you get the gist of it. The whole point of a revision control system is to not only be able to version your code, but to also let it allow you to work succinctly with all of your team members. So before I get into a typical day at the office, let's take a look at the structure of how our git repository is setup.
Repo Basics
I'm not going to go into how to setup a repository, how git is a DVCS, or how I like git better than SVN; but if you'd like I can do that in another post. We're going to nail down the basics of how our repo should function and some general terminology.
First off we have a generic repository for each project. We then use that generic repository to share code between ourselves and the deployment system. Each developer then forks that main repository and creates their own repository of the codebase as well. For instance our main repo might be developers/projectName@github, and my personal repository would be aronstaves/projectName@github. The great thing about github is they provide a few not-so-common features with their repository and also have the ability to setup private and public repositories.
For the most part, each developer in our team has access to 3 repositories.
- Local - this is each developer's git repository that's located locally on their development machine. This is what we develop in day to day.
- Origin (aaron/projectName@github) - this refers to the personal developer repository that lives remotely (on github). This is used for personal backups of branches, or for pushing branches remotely that that other developers do not need access to.
- Upstream (developers/projectName@github) - this refers to the generic repository that everyone forked their developer repositories from. Pushing branches to this repository allows you to share code with other developers as well as the deployment system. If the branch isn't in upstream, it isn't a candidate for deployment.
So in short, I develop out of my local branch every day. If I have a branch I want to save for later, or possibly an incomplete feature I want to delete locally and pull down later, I'll push it to origin. This way I'm not cluttering up upstream with various branches that other developers know absolutely nothing about, and that they probably don't care about! If I need to share code with other developers, or give the deployment system acess to code, I'll push it to upstream.
Branch Basics
Alright! Now that you see how the repos work, let's check out how branches work within a repository. At any given time, I'll have a minimum of 3 branches available. Master and Release typically are tracked against the upstream repository, and the development branch is pushed wherever it is needed. Again, these aren't rules to follow, but how I personally use git.
Master Branch
Stable Tested code. I cannot stress that enough, only stable and production tested code should be put into master. Once we've had a successful deployment of release code, we will production test it. Once tested, release code is merged into master and tagged. This branch is mainly used for breakfixes or rolling back deployment.
Release Branch
This is all code that is staged for release, but not yet tested in a production environment. Just to reiterate, if your code is not going to get released, it has no business being in this branch. Once code from a development branch has been tested by a developer, it is merged into this branch and put through QA testing.
I also want to stress working out of this branch is typically a big no-no. Not only could this lead to unwanted code getting committed to the next release, but it also has the potential to spread commits for a specific feature across non-linear commits. I'll get into the problems this can cause later, but unless you're making a single commit change to the soon-to-be released, you should make a branch for your code change.
Development
This is code that is currently being developed and is typically branched from release. So when you want to start a new feature, you'll checkout release (and make sure you have the latest code pulled down!), then create a development branch from that. I'll also go over a typical development lifecycle later as well.
Anyways, that's a quick high level overview of how I typically get things done in git. Look out in the next week or two on how I branch, rebase and merge in code with other devs on my team.
\