Introduction
Github is the place for open source. And most developers who’ve tried Git has fallen in love. As have I.
But I know for a fact that, even today (2018!), some enterprises have yet to make the switch to Git.
I’ve made that journey. I’ve lead that journey. It’s a journey that, when done properly, can give you so much back at the end of the rainbow. For us, it enabled; continuous integration and delivery, increased shipment quality and frequency, and a lot less headaches for everyone involved in the development and release process.
Background
I worked at an enterprise as Lead Developer (and Scrum Master) for about three years.
When I started, some teams where using TFVC as version control system, others used CVS. My team, a team of mainly seasoned developers, responsible for developing and maintaining the core functionality of the enterprise, used CVS.
Luckily, the (now former) Lead Developer for the front-end team, whom had a lot of influence, wanted the development teams to move to Git.
I, having some experience with Git from my previous employment, enabled us to make the move.
I held a day’s worth of training, off site, for all developers, theoretical and practical.
We migrated our code to Git. We decided we weren’t interested in migrating the version history, so we just made a clean import of a snapshot of the current code base.
Then, we were off on our own…
The development process
So, switching your version control system is not just switching your version control system. At least it wasn’t for us.
We used the opportunity to develop a new development process from scratch, not looking back at how things used to be done.
There are some great resources (mainly this is and this) on how to take advantage of Git’s light-weight branching model.
We ended up using a variant of the Gitflow workflow. And, almost three years later, it has proved to work really well.
We’re using two main branches: dev and master.
All production releases are built from master.
Development is made in feature branches from dev.
Ok, so how does this even work?
First, you also need to know a little bit about our workflow outside of the version control system.
We have four relevant roles involved in these steps; the developer, the reviewer, the tester and the merger.
This doesn’t necessarily mean that there are four people involved. In most teams, the reviewer is also the merger. I’ll get back to this soon.
The developer chooses a sprint work item and creates a new branch from dev.
We’re using TFS / VSTS / Azure Devops and decided on naming branches like in the example below.
git checkout -b pbi/12345/short-description dev
When development is complete, the developer pushes the changes to the remote and creates a pull request back to dev.
The reviewer now reviews the changes in the pull request. Assuming that everything’s ok, the reviewer approves the pull request and sends it off to the tester.
When the tester is satisfied, he or she also approves the pull request.
Now, it’s time for the merger to complete the pull request.
The merger also makes sure the associated work item is properly closed and tags it with relevant version information.
But how does the code get into
master?
With only this, one might think that the master branch is totally useless.
Why not just build from dev, since it’s a stable branch containing only tested and fully completed work?
Well, we release new versions to our customers about every other week. And these versions usually contain a mix of bug fixes, improvements and new features.
Sometimes, critical bugs are found in production, which needs fixing immediately.
To be able to provide the customers with a build containing only the latest version and the patched bug, since lots of work might have been done in dev since build, we use master.
Before building a new version, we merge dev into master. Then we tag and build from master.
By doing this, work in dev can continue without any disturbance, and master will point to the latest released version.
So when the critical bug arrives, the developer creates a branch from dev (as with any other work item), pushes the work and creates a pull request back to dev.
When the work item is reviewed, tested and merged back to dev, we grab the entire merge and put it on top of master, and we’re good to go with a new build for the patched version.
Let’s say the pull request merge to dev gave us the hash 632703b, we checkout master and then cherry-pick the entire merge:
git cherry-pick -m 1 632703b
If we have multiple work items we want in the patched version, we cherry-pick each of the merges in the exact same way.
Wrap it
That’s basically how we got Git working for us.
Hope you enjoyed the reading.
Drop a comment or contact me if you have any questions.
You’re welcome