Git / NetDevOps

Why Version Control for Network Configuration? The Change-History Problem

Advanced10 min read

What you'll learn

The real gap: rollback restores state, but keeps no history of change
What version control adds that a single rollback() call doesn't
That this module needs no external server -- a real, local capability
What this module reuses, and what's genuinely new

🎓 Teach This Lesson

Listen to a guided explanation of this lesson.

Spoken narration isn't supported in this browser.

Rollback restores state. It doesn't keep history.

A different problem than every prior module solved

NAPALM's rollback() (Phase 3.5) undoes a bad commit on one device, right now. It answers "how do I undo this." It has never answered "what changed last month, why, and who approved it." No module so far has kept a record of change over time -- only the ability to react to one change at a time.

Every module since Phase 2.6

A config or data file changeshosts.yaml, a rendered template, a NetBox record
The old version is simply goneoverwritten, no record kept
No answer to: what changed, when, why?

With version control

Every change is a commita permanent, readable record
Nothing is ever silently overwrittenold versions stay reachable
A real, readable history: what, when, and (via the message) why

Quick checkConcept check

How does this module's problem differ from what NAPALM's rollback() (Phase 3.5) already solved?

They're the same problem, solved twicerollback() undoes one bad change on one device, right now -- it keeps no record of what changed over time. This module is about the change history itself, not about undoing a single changerollback() already provides full version historyThis module replaces rollback() entirely

A real, local capability -- no external service needed

Different from NetBox, and worth naming directly

NetBox (Phase 3.7) needed a mock server, because real NetBox is a full application requiring a database. Git is different: it's a real, local tool. Nothing about this module requires a server, an account, or a network connection -- every example runs against a real, local repository.

the tool this module verifies directly, not a mock

git version 2.55.0.windows.3

Real, verified -- confirmed installed and available in this authoring environment before any lesson content was written.

Quick checkScenario

Why doesn't this module need a mock backend the way NetBox (Phase 3.7) did?

It does need one, just not built yetGit is a real, local tool -- version control works fully offline against a real local repository, with no server, account, or network dependency the way a real NetBox instance would requireGit only works with a hosted GitHub accountThis module avoids using real Git entirely

What this module reuses, and what's genuinely new

Not re-taught here

Jinja2 template rendering (Phase 2.9) and pynetbox/NetBoxInventory2 querying (Phase 3.7) are assumed known -- this module versions the OUTPUT those systems already produce, not how they produce it. Dry-run/pre-check discipline (Phase 2.8) and compare_config() (Phase 3.5) are assumed known -- this module applies the same "review before you commit to it" principle to change history itself.

Quick checkScenario

Lesson 5 of this module works with a rendered config and a NetBox-style data snapshot. Does it re-teach how those are produced?

Yes -- Jinja2 rendering and NetBox querying are re-explained in fullNo -- both are treated as already-known outputs from Phase 2.9 and Phase 3.7. This module's new material is entirely about committing, diffing, and reviewing that output over time, not producing itThis module doesn't use either artifact typeIt replaces Jinja2 and NetBox with Git-native equivalents

Quick checkConcept check

What does this module's real-device/real-service boundary (Category A/B/C) look like, compared to NetBox (Phase 3.7)?

Identical -- both need a mock and both have real, untested server behaviorDifferent: since git runs fully locally, this module's core mechanism can be genuinely verified end to end with no mock and, unlike NetBox, no expected Category C gap for undocumented server behaviorThis module has no verification boundary at allThis module is entirely Category C, since no code runs

Key takeaways

rollback() (Phase 3.5) undoes one bad change, right now -- it keeps no record of change over time. This module is about the history itself.
Git is a real, local, offline-capable tool -- verified directly installed in this environment. Unlike NetBox (Phase 3.7), no mock server is needed anywhere in this module.
Jinja2 rendering (Phase 2.9) and NetBox querying (Phase 3.7) are prerequisites, reused not re-taught -- this module versions their output.
Dry-run/pre-check (Phase 2.8) and compare_config() (Phase 3.5) taught 'review before you commit' for one device -- this module applies the same principle to change history.

Done with this lesson?

Next lesson

Git Fundamentals Through a Network Config Example

Ready to practice?

Explore hands-on exercises and assessments for this module

Practice this module