Posted on

The Agile, the Fragile, and the Iron Fist of Branching Strategies

Whether you love it or hate it, Git has proven to be the nearly ubiquitous method engineering organizations employ to ship code today. However, when you’re just getting started and building your team, you may be thinking about which strategy is the right one for you to choose based on your current and future needs.  

We recently wrote a longer article about effective branching strategies, and the considerations involved when selecting your branching strategy of choice. However, we still believe it could be useful to dive in more deeply into the underlying philosophy for each branching strategy, to help you decide what code shipping strategy is the right one for your engineering team.

Posted on

On Git and Cognitive Load

Any developer working in a modern engineering organization is likely working in git. Git, written by Linus Torvalds in 2005, has been since its creation, basically the ubiquitous tool for source control management. Git gained widespread adoption across engineering organizations as the successor to existing source control management such as Apache Subversion (SVN) and Concurrent Versions System (CVS), and this was mostly a byproduct of the timing.

Git predates cloud and improved network connectivity, and therefore the best solution to managing source control at scale was to decentralize and leverage local dev environments to power engineering organizations. Fast forward 17 years, this is no longer the case. Cloud is de facto, networking and internet connectivity is blazing fast, and this changes everything.