We have a carefully thought out git branching strategy for the PLM Web site, but I kept screwing it up, so clearly I didn't have it all straight in my head. I figured writing about it would be a good way to make sure I understand it, and might be useful for others when considering their own processes.


There are two "main" branches that developers don't work in directly, but are important to know about:

  • master: what is going to get merged into current for next release
  • current: what's currently in production

As a developer, there's usually no reason to even have current checked out, and if you don't check it out, you won't accidentally merge into it.


When a developer creates a new branch, we use a in-house tool that uses git-new-workdir to create the branch. From the git-new-workdir page:

Instead of doing a full-blown clone of your repository, it simply sets up a new working directory (with its own index) for you. The actual repository itself is shared between the original and the new working directory. This means: If you update one repository, the new commits are instantly visible in all other working directories as well. Create a new commit or branch in one of your working directories, they’re instantly available in all working directories.

Our in-house tool uses git-new-workdir to create a new working directory, create the new branch based on master, and check it out in that directory. It also creates a local database for your new branch and does other neat stuff.

Special Branches

We also have some branches that we keep around for special cases.


For fixing bugs.


This branch is used when a fix needs to be deployed and it can't wait until everything else in master has been tested and is ready to merge into current. Developers merge current into emergency before making changes and committing.


This branch is for normal sprint work where the changes you are making are trivial enough that developers don't want to create a seperate feature branch.


Once QA is done testing changes, the branch with the changes into master. At the next release, master gets merged into current, and we deploy from current. If you want to know if a given commit is on current, you can just do something like this:

git branch -a --contains fd41e23