Escape from Branchestown

Thursday, May 09, 2019 5 Comments

Branching and over engineering

Branching is a powerful tool but it has to be used wisely. Even so, when a project extends throughout the years, the sheer number of branches and changes committed to it can be impossible to handle. Unless you have an equally powerful tool like Branch Explorer.

Creating branches is an easy task for a machine. A ton of branches will never put in jeopardy the performance of your version control system (unless, well, they hold huge binaries, but that's another story). Branches, though, have another dimension to them. They are called branches because they stem out of a tree, being the tree the metaphor of the main line of development. Mainline itself is just another branch, only it's arbitrarily chosen at the beginning of each project as the branch in which the rest of the branches will be merged-to always. It will contain the latest version of the project from which the products and services are built, tested and eventually shipped.

Did you know?

Git stores branches in the shape of objects that have a pointer of the snapshot of the content committed along with its metadata. This pointer also links with the all the commits that were the direct parents of the commit that originated the object. A branch is a file that contains the SHA checksum of the commit it points to. Branches itself are not complex.

Welcome to Branchestown: branch madness

Branchestown is a metaphor of overengineering, in which the replication of main in multiple branches with minimal variations – and close to zero value for the project – imply a maintenance effort prone to chaos. Having branches called Master / Dev / Staging / Test... that have almost the same amount of code but with slight variations can only cause you trouble.

A smaller representation of this madness could be feature branches. Features branches are big themselves, one single feature of a complex enough product or service can take days or even months to finish. Imagine what an isolate team member producing a feature in a branch him or herself during weeks can break! After all, communication is key in any modern team, will the feature branch owner note to the rest of the team what classes or methods he is changing for the next weeks? Will that even be enough for them to test those changes. You can definitely use Feature Flags but hey, you're bringing new complexity to the project.

Branches however, are a tool that needs to be used wisely. Otherwise, branch madness or Branchestown can become your projects worst nightmare. If you try to picture a project with years of ongoing work, millions of lines of code and several magnitudes more of commits, what comes to mind?

Git does not provide any code base visualization other than painting it in command line which, we all know, is not the most advanced data viz tool out there. Branching is hard to understand, why not make it visually intuitive?

gmaster's Branch Explorer

Branch Explorer is an abstraction of your code base. It is painted in gmaster's GUI with intuitive elements collected in a legend.

  • Every circle in the graphic is a commit.
  • The commits are inside containers that represent the branches.
  • The diagram evolves from left to right, where commits on the right are newer than the ones on the left.
  • The green arrows are merges and the blue ones connect commits with a "is parent of" relationship.
  • The green donuts surrounding commits are tags.

The Branch Explorer lets you filter the date from where you want to render the repo, and it has zoom, a way to search, and also an action button to show "only relevant" commits. It also shows a "house icon" in the commit your workspace is pointing to at any moment

Reduce complexity, get better at DevOps

Once a bird's eye view of the project is provided, the next logical step would be to focus on specific changes. Branch Explorer will already apply a color scheme to the different levels of the codebase. Those levels are first level = main, second level = its children and so on. Branches can also be faded out so that they lose relevance when scanning through the code base.

Usually, even the cleanest of codebases can be full of changes and not all of them are relevant. Filtering out the changes that did not actually commit anything relevant to main, is also providing cleanness to the visualization. Being able to see juts the relevant changes is making the history of the project understandable at a glance.

But more importantly, having this sort of viz in place can help you understand key metrics like deployment frequency and lead time to changes. Deployment frequency, for example, can be easily tracked just by focusing on the releases, painted in green, the Branch Explorer shows. Trends, deployment hiccups or even holiday periods can be detected just with a glance at the Branch Explorer.

You can also spot Lead time to changes by viewing how bugs, for example, get to production since detected. A big fix can be traced from its initial commit in a staging branch to its final merge to main.

We develop gmaster, a Git GUI with semantic superpowers. It parses the code to really understand how it was refactored and then diff it and merge it as a human would do, matching methods instead of lines.

If you want to try it, download it from here.

We are also the developers of SemanticMerge and Plastic SCM, a full-featured version control.