Afterwood

Git comes in for a lot of stick for being a complicated tool that’s hard to learn, and they’re right, git is a complicated tool. But it’s a tool designed to solve a difficult problem – many disparate people collaborating on a single product in a totally decentralized fashion. However, many of us don’t need to work that way, so why are we using the tool in a way that makes our lives more difficult?

KISS

For my entire professional programming career, which now spans over 25 years, and my personal endeavours, I have used a version control tool (VCS) to manage the source code. In that time, for the most part, I have worked in a trunk-based development fashion [Oldwood14a]. That means all development goes on in one integration branch and the general philosophy for every commit is ‘always be ready to ship’ [c2]. (This does not preclude the use of private branches for spikes and/or release branches for hotfix engineering when absolutely needed. #NoAbsolutes.) As you might guess features toggles [Oldwood13] (in many different guises) play a significant part in achieving that.

A consequence of this simplistic way of working [Oldwood16] is that my development cycle, and therefore my use of git, boils down to these few steps:

• clone
• edit / build / test
• diff
• add / commit
• pull
• push

There may occasionally be a short inner loop where a merge conflict shows up during the pull (integration) phase which causes me to go through the edit / diff / commit cycle again, but by-and-large conflicts are rare due to close collaboration and very short change cycles. Ultimately though, from the gazillions of commands that git supports, I mostly use just those 6. As you can probably guess, despite using git for nearly 7 years, I actually know very little about it (command wise). (I pondered including ‘log’ in the list for when doing a spot of software archaeology [Oldwood14b] but that is becoming much rarer these days. I also only use ‘fetch’ when I have to work with feature branches.)

Isolation

Where I see people getting into trouble and subsequently venting their anger is when branches are involved. This is not a problem that is specific to git though, you see this crop up with any VCS that supports branches whether it be ClearCase, Perforce, Subversion, etc. Hence, the tool is not the problem, the workflow is. And that commonly stems from a delivery process mandated by the organization, meaning that ultimately the issue is one of an organizational nature, not the tooling per se.

An organisation which seeks to reduce risk by isolating work (and by extension its people) onto branches is increasing the delay in feedback thereby paradoxically increasing the risk of integration, or so-called ‘merge debt’ [Oldwood14a]. A natural side-effect of making it harder to push through changes is that people will start batching up work in an attempt to boost ‘efficiency’. The trick is to go in the opposite direction and break things down into smaller units of work that are easier to produce and quicker to improve. Balancing production code changes with a solid investment in test coverage and automation reduces that risk further along with collaboration boosting techniques like pair and mob programming. [Oldwood18]

Less is more

Instead of enforcing a complicated workflow and employing complex tools in the hope that we can remain in control of our process we should instead seek to keep the workflow simple so that our tools remain easy to use. Git was written to solve a problem most teams don’t have as they neither have the volume of distributed people or complexity of product to deal with. Organisations that do have complex codebases cannot expect to dig themselves out of their hole simply by introducing a more powerful version control tool, it will only increase the cost of delay while bringing a false sense of security as programmers work in the dark for longer.

References

[c2] ‘Always Be Ready To Ship’, available from https://wiki.c2.com/?AlwaysBeReadyToShip

[Oldwood13] Chris Oldwood ‘Codebase Stability With Feature Toggles’, published to blog 17 October 2013, available from https://chrisoldwood.blogspot.com/2013/10/codebase-stability-with-feature-toggles.html

[Oldwood14a] Chris Oldwood (2014) ‘Branching Strategies’, Overload 121 published June 2014, available from https://accu.org/journals/overload/22/121/oldwood_1920/

[Oldwood14b] Chris Oldwood (2014) ‘In The Toolbox – Software Archaeology’, published in CVu and available from http://www.chrisoldwood.com/articles/in-the-toolbox-software-archaeology.html

[Oldwood16] Chris Oldwood (2016) ‘In The Toolbox – Commit Checklist’ published in CVu and available from http://www.chrisoldwood.com/articles/in-the-toolbox-commit-checklist.html

[Oldwood18] Chris Oldwood (2018) ‘To Mob, Pair or Fly Solo’, published in CVu 30.5 (November 2018) and available from http://www.chrisoldwood.com/articles/to-mob-pair-or-fly-solo.html

Chris Oldwood is a freelance programmer who started out as a bedroom coder in the 80s writing assembler on 8-bit micros. These days it’s enterprise grade technology from plush corporate offices the lounge below his bedroom. With no Godmanchester duck race to commentate on this year, he’s been even more easily distracted by messages.