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.git

Step 2: Make Changes and Check Status

# See which files have changed
git status

Step 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 main

Branching Strategy

Branching keeps different streams of work isolated. A typical DevOps branching model:

BranchPurpose
mainProduction-ready code only
developIntegration branch for completed features
feature/loginA specific feature under development
hotfix/payment-bugUrgent 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-profile

Merging a Branch

# Switch to the target branch
git checkout main

# Merge the feature branch into main
git merge feature/user-profile

Resolving 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-text

Edit 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

CommandWhat It Does
git logShows commit history
git diffShows what changed since last commit
git stashTemporarily saves uncommitted changes
git revert [commit]Creates a new commit that undoes a previous one
git reset --hardDiscards all uncommitted changes permanently
git tag v1.0Marks a specific commit with a version label
git fetchDownloads remote changes without merging
git pullDownloads and merges remote changes

Git in a DevOps Pipeline

In DevOps, Git is the trigger for automation. Here is how it works:

  1. A developer pushes code to the main branch on GitHub.
  2. GitHub detects the push and triggers a CI/CD pipeline automatically.
  3. The pipeline runs tests, builds a Docker image, and deploys to staging.
  4. 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.

Leave a Comment