Yesterday I wrote about what continuous integration means in its purest form. Today I want to share one or two ideas on how that might be good for you.
If you do not work on a (feature) branch, you do not have to merge this branch into the master branch at some point. I don’t know how often you commit. I try to write really small commits (of the size that I change one typo in one comment and commit that already). If you work only on one branch, together with all the other developers, you have to keep your commits small. You have to commit frequently. Otherwise your work might get lost (the same way it could get lost on a branch that receives no commits).
If all developers commit all the time small amounts of work on the same branch, you will not have big merge conflicts. It will not happen, that people work on a big feature for weeks and nobody looks at the code. It will not happen that a refactoring is a big, weeks-long project that breaks everything for everyone because of merge conflicts.
Everything is a lot smaller. Everything happens in tiny iterations.
Another benefit is the effect on your tests. These are two benefits, actually. The first one: Your test coverage is higher. You wouldn’t dare commit to master and possibly breaking the build for everyone without at least some tests, would you? This could reflect bad on you if you would.
The second thing: Your test suite will be faster than a test suite that was written for the branching model. If a team of developers relies on a test suite to see whether their work was successful — after every commit — this team wouldn’t accept a test suite that runs for more than 10 minutes.
Bonus, a third advantage: Your team would tend to favour pair programming. For the simple reason that you wouldn’t have pull/merge requests.
Next week we’ll look at some disadvantages of this workflow or at least at some things I think critically about.