Version control is the discipline underneath everything else in modern software delivery: without a reliable, shared record of exactly what changed, when, and by whom, none of CI/CD, code review, or coordinated team development actually works. Git is the version control system nearly the entire industry has standardized on, and GitHub is the most widely used platform for hosting Git repositories and layering collaboration tools, pull requests, code review, issue tracking, on top of it. For a DevOps engineer specifically, Git isn’t just how code gets versioned; it’s the trigger mechanism for almost every automated pipeline. A push to a branch, a merged pull request, a new tag, these Git events are what CI/CD systems actually listen for.

This guide covers the everyday local workflow, branching and merging, pull requests and code review, resolving conflicts, and the parts that tutorials often gloss over but that come up constantly in real work: rebasing versus merging, tags and releases, working across forks and remotes, and recovering from mistakes using reset, revert, and reflog.

Git vs. GitHub: Two Different Things

You could use Git without ever touching GitHub, working entirely locally or pushing to a self-hosted server. In practice, almost every team uses a hosting platform, GitHub, GitLab, or Bitbucket, because the collaboration features (pull requests, code review, permissions, integrations) are what actually make Git useful for a team rather than a solo developer.

The Core Local Workflow

The everyday cycle of working with Git is short and repetitive once it’s familiar: make changes, stage the ones you want to commit, write a commit capturing what changed and why, and push that commit to a shared remote repository.

git status
git add app.py
git commit -m "Add health check endpoint"
git push origin main

git status shows what’s changed and what’s staged, worth running constantly to stay oriented. git add stages specific files (or git add . stages everything changed), and git commit -m records a snapshot with a message describing the change. git push sends your local commits to the shared remote repository, making them visible to the rest of the team and available to trigger any connected CI/CD pipeline.

Branching: Working Without Stepping on Each Other

Branches let multiple people work on different changes simultaneously without their in-progress work colliding. The standard pattern is a stable main branch (often called main) that always reflects production-ready code, with each new feature or fix developed on its own short-lived branch, then merged back in once it’s reviewed and tested.

git checkout -b feature/health-check
# make changes, commit them
git push origin feature/health-check
# open a pull request on GitHub
git checkout main
git pull origin main
git merge feature/health-check

git checkout -b creates a new branch and switches to it in one step. Once your work on that branch is pushed and merged (typically through a pull request rather than a direct local merge, in a team setting), switching back to main and pulling picks up the merged change, keeping your local copy in sync with the shared history.

Pull Requests and Code Review

A pull request (PR) is a request to merge one branch into another, and it’s the mechanism most teams use to enforce code review before anything reaches the main branch. Rather than merging directly, you push a branch, open a PR on GitHub comparing it against main, and teammates review the diff, leave comments, and approve before it merges. Most teams configure branch protection rules requiring at least one approval, and often a passing CI run, before the merge button is even available, which is exactly the mechanism behind the segregation-of-duties requirements covered in our compliance guide for regulated industries.

A well-written PR description explains what changed and why, not just what, since “why” is what a reviewer actually needs to evaluate whether the change is a good idea, not just whether the code itself is correct. Small, focused PRs also review far faster and more thoroughly than large ones; a 2,000-line PR touching a dozen unrelated things gets a much shallower review than five focused 200-line PRs, simply because reviewers can hold the smaller scope in their head.

Resolving Merge Conflicts

A merge conflict happens when Git can’t automatically reconcile changes to the same lines of a file made on two different branches. It’s not an error exactly, it’s Git correctly recognizing it needs a human decision. Conflicted files get marked with conflict markers showing both versions; you edit the file to keep the correct result, remove the markers, then stage and commit.

# After a conflicting merge, a file looks like:
<<<<<<< HEAD
const PORT = 3000;
=======
const PORT = process.env.PORT || 8080;
>>>>>>> feature/configurable-port

# After manually resolving, keeping the correct version:
git add app.js
git commit -m "Resolve merge conflict, use configurable port"

Conflicts are far less intimidating once you internalize that Git isn’t guessing wrong, it genuinely can’t know which version is correct when both branches changed the same lines. Reading both versions, understanding the intent behind each, and picking (or combining) the right outcome is a normal, routine part of collaborative development, not a sign something went wrong.

.gitignore and What Never Belongs in a Repository

A .gitignore file tells Git which files to never track, essential for keeping secrets, credentials, build artifacts, and dependency directories out of version control. Committing a real API key or database password to a Git repository, even briefly, is a genuine security incident, since it remains in the project’s history even after being deleted in a later commit, recoverable by anyone with repository access.

# .gitignore
node_modules/
.env
*.log
dist/
.DS_Store

If a secret does end up committed, changing the .gitignore afterward isn’t enough; the credential needs to be rotated (treated as compromised) and the commit history itself scrubbed with a tool like git filter-repo or BFG Repo-Cleaner, since simply deleting the file in a new commit leaves it fully recoverable from history.

Undoing Mistakes: Reset, Revert, and Reflog

Git gives you several tools for undoing mistakes, and picking the right one matters, especially once code has been pushed and shared. git revert creates a new commit that undoes a previous one, safe to use on shared branches since it doesn’t rewrite history. git reset moves the branch pointer backward, which is fine locally before pushing but dangerous on a branch others have already pulled, since it rewrites history they’re relying on. git reflog is the safety net: it records every place HEAD has pointed, even after a reset, making it possible to recover commits that seem to have vanished.

# Safe on shared branches: undoes a commit with a new commit
git revert <commit-hash>

# Local only, before pushing: rewinds the branch pointer
git reset --hard HEAD~1

# Recovery: shows every recent HEAD position, even after a reset
git reflog

As a general rule: use revert once anything is pushed and shared, reserve reset --hard for local, unpushed mistakes, and remember reflog exists before assuming a “lost” commit is actually gone.

Rebasing vs. Merging

Beyond a basic merge, git rebase is the other common way to integrate changes, and the two produce different-looking history. A merge preserves the actual sequence of events, including a merge commit showing where two branches came together, which some teams value for its honesty about what actually happened. A rebase replays your branch’s commits on top of the latest main, producing a clean, linear history with no merge commits, which other teams prefer for readability.

# Merge: preserves both branch histories, adds a merge commit
git checkout main
git merge feature/health-check

# Rebase: replays your commits on top of the latest main
git checkout feature/health-check
git rebase main

The one hard rule: never rebase a branch that other people have already pulled and are working from, since rebasing rewrites commit hashes, and anyone with the old history will hit confusing conflicts trying to reconcile it with the rewritten version. Rebase freely on your own local, unshared branches; merge (or use a platform’s “squash and merge” PR option) once a branch is shared with others.

Tags and Releases

Tags mark a specific commit as significant, most commonly used for release versions. Unlike branches, tags don’t move as new commits are added, they’re a fixed pointer to one exact point in history, which is exactly what you want when you need to say “this is what shipped as v2.3.0” and have that reference never change.

git tag -a v2.3.0 -m "Release 2.3.0"
git push origin v2.3.0
git tag -l

Many CI/CD pipelines are configured to trigger a production deployment specifically when a tag matching a version pattern is pushed, separating “code merged to main” from “code actually deployed to production” as two distinct, deliberate events rather than treating every merge as an automatic production release.

Forks, Remotes, and Contributing to Other Repositories

A remote is any version of a repository hosted elsewhere that your local copy can push to or pull from; origin is the conventional name for the primary remote you cloned from. A fork is a full copy of someone else’s repository under your own account, common when you don’t have direct write access and need to propose changes through a pull request from your fork back to the original.

git clone https://github.com/yourname/forked-repo.git
cd forked-repo
git remote add upstream https://github.com/original-owner/repo.git
git fetch upstream
git merge upstream/main

Adding the original repository as an upstream remote lets you periodically pull in changes from the source project into your fork, keeping it from drifting too far out of date while you work on your own contribution, a pattern that comes up constantly when contributing to open-source projects or internal repositories you don’t have direct commit access to.

Aliases and Productivity Habits

Once the fundamentals are comfortable, small configuration investments pay off over a career of daily Git use. Git aliases turn long, frequently-typed commands into short ones; a well-configured .gitignore_global handles OS-specific junk files (like .DS_Store) across every repository automatically instead of adding them per-project; and learning git log --oneline --graph for a compact, visual view of branch history makes understanding a repository’s structure far faster than the default verbose log output.

git config --global alias.co checkout
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all"

After this, git lg gives you a compact, branch-aware history view, and git co and git st save keystrokes on two of the most frequently typed Git commands. These are small conveniences individually, but they compound meaningfully across years of daily terminal use.

Git in a CI/CD Context

Nearly every CI/CD pipeline, covered in depth in our CI/CD pipelines guide, is configured to trigger off specific Git events: a push to a particular branch, a new pull request opened, or a tag matching a version pattern. Understanding this connection is what makes Git feel less like an isolated tool and more like the coordination layer for the entire delivery process: merging a PR into main is often the exact action that kicks off a deployment pipeline, which is precisely why branch protection and required reviews on that branch matter so much in a production environment.

Frequently Asked Questions

Building Real Fluency, Not Just Command Memorization

Git fluency is one of the fastest skills to fake and one of the most obvious to be missing in real work. Copy-pasting commands from a cheat sheet gets you through routine days, but the moments that actually test Git skill, a tangled merge conflict across several files, recovering a commit after a bad reset, untangling a branch that diverged further than expected, require understanding what Git is actually doing underneath the commands, not just which command to type for the common case.

The most effective way to build that understanding is deliberately breaking things in a throwaway local repository: create a test folder, make some commits, branch it, intentionally create a merge conflict, then work through resolving it without looking anything up first. That kind of low-stakes practice builds the intuition that makes the real, higher-stakes version of the same situation, on a shared repository with a deadline, feel routine instead of stressful.

Related reading: continue to CI/CD pipelines, review the CI/CD tools guide for platform comparisons, or return to the full topics overview.