Git is the rage, we are all rushing to move over to it. But there is a critical problem, git allows for almost any workflow imaginable. I mean, I can use a straight svn style workflow with a master (similar to svn trunk) branch and have development or release branches from that. I can implement the rather common nvie workflow or use a Gerrit workflow. I can come up with some other masochistic workflow. So what is the best git workflow. Honestly, I don’t know. It truly depends on your needs and your situation.
For open source projects, it seems that forking and merging back into a master repository is working well. For businesses, well they are still trying to grasp what git is and how they can utilize it effectively. What I have found works rather well for Assembla, boasting 25-30 developers at any given time, is a forked network that has one repository per developer and a common origin.
So here is the story, Assembla transitioned to git and did what everyone was doing, had no idea how to work in it - so we used it, as I like to call it, “subversion-style”. It was not utilizing the power of git for what it was, but it worked, so why fix it? Well, keep reading to understand why. We were releasing about 1-2 times per month, nothing impressive. We got our features out and they had bugs. We would fix them. The team was typically stressed, we were either in a release sprint or in a bug fixing mode. There seemed little time to breathe and releases started getting more complicated and more error prone as time went on. We knew this had to change. We realized that we had to move QA and the way developers were working in the codebase. Read more about our workflow and conclusions where we Learned to Avoid Premature Integration. This took a radical change to the way we worked in git. In the end we are releasing software several times a day while the development team has less stress and issues because of the process change.
Our developers work in forks, with a common origin. This allows them to have as many branches as they like and create whatever tags they deem necessary without interfering with anyone else, as well as break their build or have unreleasable code in it. They then merge their work upstream as well as merge changes from upstream to get other peoples work. Since all the work is pivoting around a common origin, and since this common origin is always considered stable, the work is able to be integrated with production code and shared amongst developers without conflicting with each other. Of course conflicts will occur, but they are dealt with by the person who contacts them. Read more about this problem where we explain the Continuous Delivery process. The basic structure looks something like this:
Its very simple, but that is what makes it so flexible. One developer will not block another developer’s work. Prior to code being merged into origin/master, origin/master must be merged back to the dev/master repository or a temporary branch from origin/master with the merge set from the dev/master repo must be created to test for conflicts or test other issues. Whenever code is committed to origin/master, it must be considered stable and ready for deployment to production. We use Merge Requests internally to control the flow of code from developer’s repositories to origin, read about how you can use Merge Requests to Code Review.
The above process can be used in teams as well, allowing for a more rigid architecture, and more control points. If we move the developers down into branches on a team branch, and have them submit Merge Requests up to the team/master, then teams submit Merge Requests from their team/master to origin/master. This is where Assembla went before transitioning developer’s into their own forks. We had a git architecture that looks like this:
Now the work is aggregated into team/master before going forward into origin/master. We found that often releases were delayed and one developer’s work would interrupt another developers work. We only moved the problematic points to team/master instead of origin/master. By moving the pain points to dev/master, we keep the problem where it belongs, at the developer’s fingertips.
Assembla recently finalized the switch to working in developer only repositories, we have seen great success so far. And every developer is learning more about the tool that seems so hard for many to grasp - git. And we know that it is already far better than our “subversion-style” workflow:
To learn more about how to utilize Assembla to achieve a better workflow, read Git Review and Merge Like a Boss and Avoiding Premature Integration: or How we learned to stop worrying and ship software everyday.