Git workflows

Everything in DevOps, from app code to infrastructure and pipeline definitions, lives in Git and changes through reviewed commits.

Branches and pull requests

Also called PR, merge request, MR, pull request, branch

What: A branch is a movable pointer to a line of commits. A pull request proposes merging a branch, runs CI checks and collects review before the change lands.
Why: Pull requests are where changes are tested and reviewed, and branch protection rules make that mandatory for the main branch.

Shell

git switch -c fix/nginx-timeout
git add nginx.conf
git commit -m "Raise proxy timeout for uploads"
git push -u origin fix/nginx-timeout

Merge vs rebase

Also called rebase

What: git merge joins histories with a merge commit. git rebase replays your commits on top of another branch, giving a straight line of history.
Why: Rebasing a feature branch onto main before merging keeps history readable. Merging preserves exactly what happened.

Watch out

Rebasing a branch others have pulled rewrites shared history; use git push --force-with-lease, never plain --force, and only on your own branches.

Trunk-based development

Also called GitFlow

What: Everyone merges small changes into one main branch at least daily, hiding unfinished work behind feature flags. GitFlow instead keeps long-lived develop and release branches.
Why: Short-lived branches mean fewer merge conflicts and fit continuous delivery. Most teams with CI/CD have moved to trunk-based work.

Undoing changes: revert vs reset

What: git revert adds a new commit that undoes an earlier one. git reset moves the branch pointer back, discarding or unstaging commits. git restore discards file changes.
Why: On shared branches revert is safe because it does not rewrite history. Reset is for local commits that nobody else has.

Watch out

Running git reset --hard on uncommitted work: it is gone. git reflog can recover lost commits, but not changes never committed.

Tags and semantic versioning

Also called semver, release tags

What: A tag names a specific commit, such as v2.4.1. Semantic versioning uses MAJOR.MINOR.PATCH: breaking changes, new features, fixes.
Why: Tags mark exactly what was released and often trigger release pipelines and image builds.

.gitignore and secrets in Git

Also called gitignore, committed secrets, secrets in Git

What: .gitignore lists files Git should not track, such as .env, build output and Terraform state. Once a secret is committed, it stays in history even after deletion.
Why: Leaked keys in public repos are found by bots within minutes. Prevention is far cheaper than cleanup.

Watch out

Deleting a leaked key from the latest commit and moving on: rotate the key immediately, then clean history.

Go deeper