Version Control

A version control system records changes to files over time. It gives a project a shared history, allowing people to compare versions, review changes, work in parallel, and restore an earlier committed state.

Source code is the common example, but version control is also useful for documentation, infrastructure definitions, automation, and text-based device configurations.

The Shared-Folder Problem

Without version control, a team may exchange copies through a shared folder:

project/
├── app-final.py
├── app-final-lalit.py
├── app-final-v2.py
└── app-final-v2-fixed.py

This creates unanswered questions:

Which copy is current?
What changed between two copies?
Why was the change made?
Can two changes be combined safely?
Which version was deployed?
How can one bad change be reversed without discarding later work?

A version control system stores named checkpoints and the relationships between them:

A1 ── A2 ── A3 ── A4
      │     │     │
      │     │     └─ fix timeout handling
      │     └─────── add API retry logic
      └───────────── initial working version

In Git, these checkpoints are called commits.

What Version Control Provides

Capability	Practical use
History	Inspect earlier committed states
Difference comparison	See exactly which tracked lines changed
Attribution	Record the author and committer associated with a commit
Branching	Develop a change without immediately altering the main line
Merging	Combine compatible work from different branches
Review	Discuss and approve a proposed change before merging
Recovery	Restore tracked content from an earlier commit
Traceability	Connect a change with an issue, review, test, or release

Key Insight: Version control records changes. It does not prove that a change is correct, prevent bugs, or automatically protect every file on the machine.

Version Control, Git, and GitHub

These names are related but not interchangeable:

Term	Meaning
Version control system (VCS)	The general category of tools that record file history
Git	A distributed version control system
GitHub, GitLab, Bitbucket	Platforms that host Git repositories and add collaboration features such as pull requests, issues, permissions, and CI/CD integration

Git can be used entirely on one computer. A hosting platform becomes useful when a team needs a shared remote repository, review workflow, access controls, or automation.

Core Git Terms

Term	Beginner-friendly meaning
Repository	The project files plus version-control history
Working tree	The files currently checked out for editing
Staging area	The selected changes intended for the next commit
Commit	A recorded project snapshot with metadata and a parent history
Branch	A movable name pointing to a line of commits
Merge	Combining histories and their changes
Remote	A named reference to another repository, often hosted on a server
Clone	A local copy of a Git repository, normally including its history

Git conceptually stores project snapshots. Unchanged files are referenced efficiently rather than stored as a completely new physical copy in every commit.

Centralized and Distributed Version Control

Centralized model

Developer A ─┐
Developer B ─┼──► Central repository
Developer C ─┘

A centralized VCS keeps the authoritative history on a central server. Clients normally depend on that server for many version-control operations.

Examples include Subversion and Perforce.

Distributed model

Developer A repository ◄────► Shared remote ◄────► Developer B repository
   files + history                                  files + history

Git is distributed. A normal clone contains the repository history, so developers can inspect history and create commits locally. A shared remote is still commonly used as the team’s official integration point.

Distributed does not mean every copy is automatically synchronized. Developers must explicitly fetch, pull, or push changes.

A Common Collaboration Flow

flowchart LR
    Issue["Issue or requested change"] --> Branch["Create a branch"]
    Branch --> Edit["Edit and test"]
    Edit --> Commit["Create commits"]
    Commit --> Review["Open a pull request"]
    Review --> Checks["Review and automated checks"]
    Checks --> Merge["Merge into the main branch"]

The exact workflow varies, but the responsibilities remain distinct:

An issue tracker records bugs, requests, decisions, and work status.
Git records file history.
A pull request or merge request presents a proposed set of changes for review.
CI tools run automated checks.
A deployment system moves an approved version into an environment.

One product may provide all these features, but they remain separate concepts.

A Small Git Example

# Create a repository in the current project directory
git init
 
# Select one file for the next commit
git add configs/core-switch.txt
 
# Record the staged snapshot
git commit -m "Record core switch OSPF configuration"
 
# Inspect the concise commit history
git log --oneline

git add does not upload the file. It adds the current file content to Git’s staging area. git commit records the staged snapshot in the local repository. Sharing it with another repository requires a separate git push.

What Belongs in Version Control?

Good candidates	Usually poor candidates
Source code	Build output that can be recreated
Documentation	Dependency directories such as `.venv` or `node_modules`
Tests	Temporary files and logs
Infrastructure-as-code definitions	Large binary files that change frequently
Ansible playbooks and roles	Live database files
Configuration templates	High-frequency telemetry dumps
Small, sanitized text configurations	Passwords, API tokens, private keys, and unencrypted secrets

Git can store binary files, but line-by-line comparison and merging work best with text. Large or frequently changing binary assets may need Git LFS or an artifact/object store.

Version Control Is Not a Complete Backup

Git helps recover committed, tracked content. It does not automatically protect:

uncommitted changes
untracked or ignored files
credentials deliberately excluded from the repository
external databases, artifacts, or runtime state
a repository when every copy and remote is lost or access is unavailable

Use a remote repository and an appropriate backup policy. Version control and backup solve overlapping but different problems.

Network and Infrastructure Use Cases

Version control is valuable for network automation:

Ansible playbooks, roles, templates, and non-secret variables
infrastructure-as-code definitions
intended device configurations
sanitized configuration snapshots
policy and validation rules
change documentation

A configuration workflow can connect intent with execution:

Issue
  → configuration or playbook change
  → review and tests
  → approved commit
  → automation deployment
  → device and deployment audit logs

Git records who authored and committed the repository change. It does not by itself prove who changed the live device. Someone may alter the device manually, or an automation account may deploy a different version. Reliable attribution requires deployment logs, device accounting or audit logs, and a link back to the commit.

Restoring an old file in Git also does not roll back a switch automatically. The desired configuration must be deployed, checked for compatibility with current state, and validated.

Operational data

Text snapshots of routes, neighbor adjacencies, or interface state can be useful for a small lab or a targeted before-and-after comparison. Continuously changing operational data usually belongs in monitoring, logging, telemetry, or time-series systems that provide retention and query controls.

Do not turn every polling result into a Git commit. That creates noisy history and makes meaningful configuration changes harder to find.

Working with Other Developers’ Libraries

Version control supports both using and contributing to shared libraries:

A library maintainer publishes source and releases from a repository.
Users report defects or request features through an issue tracker.
Contributors create a branch or fork.
They propose commits through a pull request.
Maintainers review, test, and merge acceptable changes.

Installing a released library and contributing to its source repository are separate workflows. A package installer such as pip consumes a distribution; Git manages the source history.

Common Mistakes

Committing secrets and assuming a later deletion removes them from history
Using unclear messages such as fix or changes
Mixing unrelated work in one commit
Committing generated dependency or build directories
Treating the main branch as a shared folder with no review
Assuming a successful merge means the software works
Force-pushing shared history without team agreement
Treating Git as the source of truth while allowing untracked manual production changes

TL;DR

Version control records file changes and creates a shared project history.
Git is one distributed version control system; GitHub and similar platforms host repositories and add collaboration tools.
Commits are recorded snapshots, while branches allow parallel work.
Issue tracking, code review, CI, deployment, and version control solve different parts of collaboration.
Version control helps recover committed files but does not replace a complete backup strategy.
Infrastructure definitions and sanitized configurations fit Git well; secrets and high-frequency operational data do not.
A Git author record describes a repository change, not necessarily the person or system that changed a live device.

Continue with Git Fundamentals for repositories, the working tree, staging area, and commits.

Resources

Note: Concepts and current documentation links were checked against official Git, GitHub, and Ansible documentation in July 2026.

Lalit's Cloud & DevOps notes