Damian ONeill

Breaking stuff since 72

3 minute read

After years in network engineering and software development environments, I’ve observed a troubling but rarely discussed reality: a significant proportion of engineers simply don’t understand Git beyond a narrow set of memorised commands. This isn’t entirely their fault – Git’s design prioritises flexibility and power over intuitive operation, creating a steep learning curve that many professionals quietly navigate by developing muscle memory for a handful of commands that “just work.”

The Illusion of Git Mastery

Look around your team and you’ll likely recognise these patterns:

  • Engineers who can confidently push, pull, commit, and create simple branches, but panic when faced with a merge conflict or detached HEAD state
  • Developers who rely on GUI tools exclusively because the command line interface feels impenetrable
  • Team members who’ve never used git rebase, git cherry-pick, or git reflog, despite years of “experience” with Git
  • The occasional situation where someone accidentally force-pushes to main, followed by an hour of frantic recovery efforts

This limited understanding isn’t immediately obvious because Git’s basic operations cover perhaps 80% of daily needs. The problem emerges when teams adopt increasingly complex branching strategies that push beyond this comfort zone, often justified with impressive-looking flow diagrams and theoretical benefits.

The Command Comfort Zone

For many engineers, Git competency consists of a reliable sequence of commands they’ve memorised:

git checkout -b feature-branch
git add .
git commit -m "message"
git push

And when it’s time to update (manually or with a UI (Gitlab or Github)):

git checkout main
git pull
git checkout feature-branch
git merge main
git push

There’s nothing inherently wrong with this pattern. The issues arise when complex branching strategies require operations beyond this comfortable subset—operations like resolving complicated merge conflicts, interactive rebasing, or managing multiple remote tracking branches.

When Branching Models Become Burdensome

Complex branching strategies like GitFlow were designed for specific contexts: managing multiple parallel release versions with formal QA cycles and scheduled releases. Yet I’ve watched teams adopt these heavyweight processes for projects where they’re entirely inappropriate.

The overhead becomes visible in several ways:

  • Project management friction: More branches mean more pull requests, more code reviews, and more merge operations
  • Cognitive load: Developers must track which changes live in which branches and how they relate
  • Integration delays: Changes remain isolated longer, increasing the likelihood of painful merge conflicts
  • Workflow confusion: More steps mean more opportunities for team members to make mistakes

For network automation teams, for instance, where many engineers come from traditional networking backgrounds rather than software development, these complex strategies create unnecessary barriers. I’ve seen skilled network engineers struggle with rebasing feature branches onto release branches, not because they lack intelligence, but because the mental model is unnecessarily complex for their actual needs.

A Case for Branching Minimalism

After witnessing these challenges across multiple organisations, I’ve become an advocate for branching minimalism: using the simplest branching strategy that meets your needs, not the most sophisticated one you can diagram.

For many teams, this means:

  1. A protected main branch representing the current state of production
  2. Short-lived feature branches for individual changes
  3. A clear, simple path to integrate changes into main

This approach acknowledges the reality of how most engineers interact with Git. It plays to the strengths of what people actually understand rather than what they theoretically should know.

For more complex projects, you might add:

  1. Release branches that fork from main at specific points
  2. Hotfix processes for emergency production fixes

But each additional element should justify its complexity by solving real problems, not theoretical ones.

Improving the Situation

Rather than implementing elaborate branching schemes, consider these alternatives:

  • Invest in better testing: Automated tests provide more reliable quality guarantees than complex branch gatekeeping
  • Shorten the feedback loop: Integrate changes more frequently in smaller batches
  • Improve Git education: Create team-specific guides that focus on the exact Git operations your workflow requires
  • Simplify your branching model: Challenge whether each branch type genuinely adds value

The goal shouldn’t be Git mastery for its own sake, but rather finding the simplest processes that enable your team to deliver value efficiently and confidently. Often, that means acknowledging the real limitations in how comfortably most engineers navigate Git’s complexity.

When you find your team spending more time managing branches than solving actual problems, it’s time to reconsider whether your branching strategy is serving its purpose.

You May Also Enjoy