How would you use Git to manage network changes?
Show the answer
Say this first
Everything that defines the network (templates, variables, playbooks, intended configs) lives in a Git repo. Each change is a short-lived branch, opened as a pull or merge request that runs automated checks and gets a peer review. Merging to main means "approved", and the pipeline deploys main. Git gives history, a diff of every change, who made it and why, and an easy way to revert.
Go deeper
The everyday flow
git clone git@git.example.com:netops/network.git
cd network
git switch -c CHG1234-add-vlan-30
# edit data/sites/dc1/vlans.yml
git add data/sites/dc1/vlans.yml
git commit -m "CHG1234: add VLAN 30 GUESTS to dc1 leaves"
git push -u origin CHG1234-add-vlan-30Then open a merge request. CI lints, renders and dry-runs the change, a reviewer approves, and it merges.
Commands worth knowing
| Command | Use |
|---|---|
git status, git diff | What changed and is not committed yet |
git log --oneline | Short history |
git blame file | Who last changed each line |
git revert <commit> | New commit that undoes an old one, safe on shared branches |
git pull | Fetch and merge the latest from the remote |
What goes in, what stays out
In: templates, data, playbooks, scripts, tests, pipeline files. Out: secrets (use Vault), generated files you can rebuild, and huge binary images. Config backups usually live in a separate repo.
They will ask next
Why
git revertand notgit resetto undo a bad change?revertadds a new commit, so history stays intact and everyone's copy stays valid.resetrewrites history, which breaks other people's clones when the branch is shared.Merge or rebase?
Rebasing your own feature branch onto main before the merge gives a clean, linear history. Never rebase a branch other people already pulled. Many teams squash-merge short change branches into main.
Traps
- Long-lived branches per engineer that drift away from main and conflict at merge time.
- Committing passwords. Git history keeps them even after deletion.