Fork Yeah! Git in Network Engineering

Git has revolutionized software development over the past two decades, but many network engineers still view it as a tool exclusively for developers. This mindset creates an artificial barrier between networking professionals and powerful tools that could dramatically improve their workflows and productivity. As we explored in our recent episode of The Art of Network Engineering, this resistance often stems from a fundamental misunderstanding about what Git actually is and how it can benefit network operations.

A Tool is Just a Tool—Until It Isn’t

As Andy Lapteff 🛠️💬 points out in the episode, tradespeople like carpenters and plumbers don’t refuse to use tools simply because they weren’t “meant” for their trade. So why do network engineers draw such rigid lines when it comes to tools like Git?

“I’ve worked as a plumber’s helper, a carpenter’s helper… and you never say, ‘That tool’s not for me.’ But I’ve totally said that about software tools—‘That’s not networking,’” Andy admitted. This kind of thinking, while common, limits our ability to evolve and solve problems more efficiently.

Git’s Origins and Why It Matters

William Collins helped contextualize Git by tying it back to its origin story. Git was created by Linus Torvalds—the same person behind Linux—to manage the growing complexity of the Linux kernel project. It was never about source code alone; it was about collaboration, change tracking, and distributed workflows.

That’s where the magic lies for network engineers: Git gives you the ability to track changes in configuration files, collaborate across teams, and maintain a clear, auditable history of who changed what and when.

As Colin Doyle noted, “Git is simply a link in the chain of maintaining continuity of information… It formalizes storage and collaborative workflows we’ve always needed.”

Git for Network Engineers: Real Use Cases

Imagine a Git-based workflow for something as simple (and familiar) as prefix-list changes. Instead of emailing config snippets back and forth for peer reviews or trying to figure out which “_v2_FINAL_REALFINAL” file is the latest, you could:

  1. Create a branch from a main config repository.
  2. Make your changes (e.g., adding a prefix to a list).
  3. Submit a pull request for peer review.
  4. Have it approved and merged, with a clear audit trail and rollback capability.

This process doesn’t replace your CLI skills or your knowledge of devices—it complements them. Git becomes the foundation for better collaboration, more consistent change management, and easier troubleshooting.

Familiar Territory in Disguise

Git’s distributed nature might sound complex at first, but William drew a helpful comparison: it’s not unlike BGP or OSPF. “Each node keeps its own state. Updates are distributed. Eventually, everyone converges on a common view,” he explained.

When you think of Git as a network of repositories, syncing and merging updates just like routing tables do, it becomes far less foreign. It’s distributed state management, just applied to file systems instead of packets.

It Doesn’t Have to Be All or Nothing

One of the biggest takeaways from the episode was the idea that you don’t need to be a Git wizard to get started. Colin emphasized that you can start small—use Git as a backup tool, store configurations, or track spreadsheet versions. The core commands you need—clone, commit, push, pull, and branch—are easy to learn and can offer immediate value.

William put it best: “There’s not a more powerful tool to underpin the principles of uptime, complexity management, and change control in 2025 than Git.”

Final Thoughts

Git isn’t just for coders—it’s for anyone who works with files that change over time and need to be shared, reviewed, and versioned. That includes network engineers.

If you’ve ever been burned by version confusion, config drift, or lack of peer review, Git can be your ally. And no, you don’t have to understand every feature or use it the way a software developer does. Just start using it in a way that helps you—and build from there.

As Andy said in the closing moments of the episode, “The biggest thing I’ve learned is that disqualifying a tool before I even investigate it is a mistake. Git can solve a problem I’m having right now at work.”

Listen to the episode here: https://www.buzzsprout.com/2127872/episodes/16942088

Leave a comment