What is git for DevOps?
Beyond commit and push, git is the source of truth that pipelines watch and act on. In DevOps, a push to a branch can trigger a build, a tag can cut a release, and a merge can deploy. Understanding git's model deeply is what makes those automations reliable.
Why it matters
Git is the trigger and the audit log for everything that ships. GitOps takes this further — the desired state of your infrastructure lives in git, and tools reconcile reality to match. A shaky grasp of branches and history makes every pipeline fragile and every rollback scary.
What to learn
- The commit graph: branches, HEAD, and refs
- Merge vs rebase, and when each fits
- Tags and how releases use them
- Git hooks for local and server-side automation
- Resolving conflicts confidently
- Branch protection and required checks
- GitOps: git as the source of truth for infrastructure
Common pitfall
Force-pushing a rebased shared branch and overwriting teammates' work. Rebase
rewrites history, which is fine on your own un-pushed commits but destructive on
a branch others have pulled. Rebase local work, merge shared work, and treat
--force on shared branches as a last resort with a warning.
Resources
Primary (free):
- Pro Git (free book) · docs
- Atlassian — Git tutorials · docs
- GitOps — OpenGitOps principles · docs
Practice
Create a feature branch, make a few commits, then rebase it onto an updated main and resolve a conflict. Tag a release. Add a simple pre-commit hook that blocks a commit if a lint check fails. Done when you can explain the difference between your rebase and a merge in the history.
Outcomes
- Reason about the commit graph, branches, and refs.
- Choose merge vs rebase and avoid rewriting shared history.
- Use tags and hooks to support releases and automation.
- Explain how GitOps makes git the source of truth.