DevOps Version Control with Git
Version control is a system that records changes to files over time. It lets teams track who made a change, what was changed, and why. In DevOps, version control is the starting point of every automated pipeline.
Git is the most widely used version control system in the world. It stores code in a repository (a special folder that tracks all changes). Git works locally on a developer's machine and can sync with remote platforms like GitHub, GitLab, or Bitbucket.
Why Version Control Matters in DevOps
Without version control, teams face serious problems:
- Two developers overwrite each other's work.
- A bug is introduced and no one knows which change caused it.
- Rolling back a bad release means manually undoing dozens of changes.
Git solves all of these. Every change is recorded with a timestamp, author name, and a message explaining the change. Rolling back is a single command.
Basic Git Concepts
Repository (Repo)
A repository is a folder that Git monitors. It stores all project files and the complete history of every change ever made to those files.
Commit
A commit is a saved snapshot of the project at a specific point in time. Think of it like a photograph — every time something meaningful changes, take a photo and label it.
Branch
A branch is a separate line of development. The default branch is usually called main or master. Developers create new branches to work on features or bug fixes without disturbing the main codebase.
Merge
Merging combines changes from one branch into another. Once a feature is complete and tested, it gets merged back into the main branch.
Clone
Cloning copies a remote repository to a local machine so work can begin.
Push and Pull
Push sends local commits to the remote repository. Pull downloads the latest changes from the remote repository to the local machine.
Setting Up Git
After installing Git, configure identity with these two commands:
git config --global user.name "John Smith"
git config --global user.email "john@example.com"This information attaches to every commit made on this machine.
Basic Git Workflow
Here is a simple day-to-day Git workflow:
Step 1: Initialize or Clone a Repository
# Start a new repo in the current folder
git init
# OR clone an existing remote repo
git clone https://github.com/example/myapp.gitStep 2: Make Changes and Check Status
# See which files have changed
git statusStep 3: Stage Changes
Staging means selecting which changes to include in the next commit.
# Stage a specific file
git add index.html
# Stage all changed files
git add .Step 4: Commit Changes
git commit -m "Add login page with email validation"Step 5: Push to Remote
git push origin mainBranching Strategy
Branching keeps different streams of work isolated. A typical DevOps branching model:
| Branch | Purpose |
|---|---|
| main | Production-ready code only |
| develop | Integration branch for completed features |
| feature/login | A specific feature under development |
| hotfix/payment-bug | Urgent fix for a production issue |
Creating and Switching Branches
# Create a new branch
git branch feature/user-profile
# Switch to that branch
git checkout feature/user-profile
# Create and switch in one command
git checkout -b feature/user-profileMerging a Branch
# Switch to the target branch
git checkout main
# Merge the feature branch into main
git merge feature/user-profileResolving Merge Conflicts
A merge conflict happens when two developers changed the same line in the same file. Git cannot decide which version to keep and marks the conflict for manual resolution.
Example conflict marker in a file:
<<<<<<< HEAD
Welcome to the homepage
=======
Welcome to our platform
>>>>>>> feature/new-textEdit the file to keep the correct version, then stage and commit:
git add index.html
git commit -m "Resolve merge conflict in homepage text"Useful Git Commands Reference
| Command | What It Does |
|---|---|
| git log | Shows commit history |
| git diff | Shows what changed since last commit |
| git stash | Temporarily saves uncommitted changes |
| git revert [commit] | Creates a new commit that undoes a previous one |
| git reset --hard | Discards all uncommitted changes permanently |
| git tag v1.0 | Marks a specific commit with a version label |
| git fetch | Downloads remote changes without merging |
| git pull | Downloads and merges remote changes |
Git in a DevOps Pipeline
In DevOps, Git is the trigger for automation. Here is how it works:
- A developer pushes code to the main branch on GitHub.
- GitHub detects the push and triggers a CI/CD pipeline automatically.
- The pipeline runs tests, builds a Docker image, and deploys to staging.
- If all checks pass, the code goes to production.
Without Git, none of this automation is possible. Git is the foundation that everything else in DevOps builds upon.
Real-World Example
Three developers work on the same e-commerce site:
- Developer A works on
feature/cart-discount - Developer B works on
feature/product-search - Developer C fixes a bug on
hotfix/checkout-crash
All three work simultaneously without interfering with each other. When each task is complete, it gets merged into develop, tested together, then merged into main for release.
Summary
- Git tracks all changes to code with full history, author info, and timestamps.
- Branches allow parallel development without conflicts.
- Commits are snapshots — descriptive messages make history readable.
- In DevOps, a Git push triggers automated pipelines for testing and deployment.
- Platforms like GitHub, GitLab, and Bitbucket host remote Git repositories and add collaboration features.
