From CI/CD pipelines and Infrastructure as Code to Kubernetes deployments and application releases, almost every automation workflow begins with a change in a Git repository. A commit, push, merge, or tag can trigger an entire deployment pipeline automatically.
Understanding Git isn't just about version control—it's about understanding the foundation that modern software delivery is built on.
Why Git Matters in DevOps
Think about the Software Development Life Cycle (SDLC):
Plan → Code → Build → Test → Release → Deploy → Operate → Monitor
Git sits at the center of this workflow.
When code changes are committed and pushed:
- CI/CD pipelines automatically start
- Tests run automatically
- Docker images get built
- Deployments can be triggered
- Infrastructure changes can be tracked
- Teams can collaborate safely
In many organizations, Git becomes the single source of truth for both application code and infrastructure configuration.
What Is Git?
Git is a Distributed Version Control System (DVCS) that tracks changes to files over time.
It allows developers to:
- Track project history
- Revert mistakes
- Collaborate with teams
- Create isolated branches
- Maintain a complete record of changes
Unlike older centralized systems, Git is distributed.
What Does "Distributed" Mean?
Every copy of a Git repository contains the complete project history.
This means:
- You can work offline
- You can create commits without internet access
- Every clone acts as a backup
- There is no single point of failure
When you clone a repository, you're not just downloading files—you're downloading the entire project history.
This is why platforms like GitHub, GitLab, and Bitbucket are not Git itself.
Git is the version control system.
GitHub and similar platforms simply provide a shared remote location where teams can collaborate.
Understanding Git's Snapshot Model
One of the most misunderstood concepts in Git is how it stores history.
Many beginners assume Git stores only the differences between files.
That's not how Git works.
Git Stores Snapshots
Every commit represents a complete snapshot of the project at a specific moment.
Commit A → Commit B → Commit C
Snapshot Snapshot Snapshot
of all of all of all
files files files
Think of each commit as a photograph of your project.
When you return to a previous commit, Git simply restores that snapshot.
This design makes operations like:
- Switching branches
- Viewing history
- Restoring previous versions
extremely fast and efficient.
Behind the scenes, Git avoids storing duplicate file data when files haven't changed, making storage efficient while maintaining the snapshot model.
The Three Areas of a Git Project
To understand Git properly, you need to understand its three working areas.
Working Directory
|
git add
↓
Staging Area
|
git commit
↓
Repository
1. Working Directory
This is where you actively edit files.
Any changes made here are considered unstaged changes.
2. Staging Area
The staging area acts as a preparation zone.
You decide exactly which changes should be included in the next commit.
This allows you to create clean and focused commits instead of committing everything at once.
3. Repository
The repository contains committed snapshots and project history.
Once changes are committed, they become part of Git's permanent history.
Creating a Git Repository
To start tracking a project with Git:
git init
This command creates a hidden .git directory.
The .git folder stores:
- Commit history
- Branch information
- Configuration
- Repository metadata
Without the .git folder, Git history does not exist.
Configure Your Identity
Git records who created each commit.
Set your identity once per machine:
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git status: Your Most Important Command
If there's one Git command you'll use constantly, it's:
git status
This command tells you:
- Which files have changed
- Which files are staged
- Which files are untracked
- What will happen next
Whenever you're unsure about your repository's state:
git status
is the first command to run.
Staging Changes with git add
Before creating a commit, changes must be staged.
Stage a Single File
git add file.txt
Stage Multiple Files
git add file1.txt file2.txt
Stage Everything
git add .
Interactive Staging
git add -p
This allows you to choose specific portions of a file to stage.
Be Careful with git add .
While convenient, git add . stages everything.
Always verify what's staged:
git status
before creating a commit.
Creating Snapshots with git commit
Once changes are staged:
git commit -m "Add user authentication endpoint"
This creates a permanent snapshot of the project.
The -m flag allows you to write the commit message directly in the command.
Without it, Git opens your default text editor.
Writing Better Commit Messages
Good commit messages save time for both you and your team.
Avoid Messages Like:
fix
update
changes
test
final
final-final
Prefer Messages Like:
feat: add user authentication endpoint
fix: resolve null pointer exception in payment service
docs: update installation guide
refactor: simplify database connection logic
test: add unit tests for user service
chore: upgrade nginx package version
ci: add GitHub Actions deployment workflow
This makes history easier to read and understand.
Viewing Project History with git log
Git provides several ways to inspect history.
Full History
git log
Displays:
- Commit hash
- Author
- Date
- Commit message
Compact View
git log --oneline
Example:
a1b2c3d Add authentication
e4f5g6h Fix API validation
i7j8k9l Initial project setup
Visual Branch Graph
git log --oneline --graph
Useful when working with multiple branches.
Show Actual Code Changes
git log -p
Displays the content changes for each commit.
Filter by Author
git log --author="John"
Filter by File
git log -- filename.txt
Shows only commits that modified a specific file.
Understanding Commit Hashes
Every commit has a unique identifier called a commit hash.
Example:
a1b2c3d4e5f67890abcdef1234567890
The hash is generated from:
- Commit content
- Metadata
- Parent commit information
Even the smallest change creates a completely different hash.
In practice, you'll usually use only the first few characters:
git checkout a1b2c3d
Git can usually identify the correct commit from a short unique prefix.
Key Takeaways
Git is much more than a tool for saving code.
It is:
- The foundation of CI/CD pipelines
- The source of truth for modern infrastructure
- The backbone of collaborative software development
- The trigger behind most DevOps automation
Before learning branches, pull requests, Docker, Kubernetes, or Terraform, it's important to understand how Git stores history and manages changes.
Master these fundamentals, and every DevOps tool that follows will make much more sense.
Happy learning! 🚀
Top comments (0)