Skip to content
Expert GitLesson 5 of 5 2 min read

Git Workflows & GitOps

Trunk-based development, pull requests, and using git itself as the source of truth for what should be running.

Skip to the challenge
On this page4 sections

Branches and commits are the mechanics. A workflow is the team-wide agreement on how those mechanics actually get used day to day.

Trunk-based development vs. Git Flow

  • Trunk-based development - everyone branches off main for a short-lived feature branch (hours to a couple of days), merges back quickly, and main is always close to deployable. Favored by teams practicing continuous deployment.
  • Git Flow - a heavier model with long-lived develop, release, and hotfix branches alongside main. More structure, more ceremony - a reasonable fit for software shipped in discrete, versioned releases rather than deployed continuously.

Most modern web teams lean toward trunk-based development specifically because it pairs well with the CI/CD pipelines from earlier in this track - the whole point of fast feedback is undercut if branches sit unmerged for weeks.

Pull requests

A pull request (or "merge request") is the review gate before a branch merges: a diff, a place for teammates to comment line-by-line, and (usually) a requirement that CI passes before the merge button even unlocks. It's the social and quality-control layer git itself doesn't provide on its own.

GitOps

GitOps takes this a step further for infrastructure and deployments: the desired state of a system - which image version should be running, how many replicas, which config - is described declaratively and committed to a git repository. An operator (often running inside the cluster itself) continuously compares that desired state against what's actually running, and reconciles any difference automatically.

The result: deploying is just a commit and a pull request, exactly like shipping a code change. Rolling back is git revert. And the git history itself becomes a complete, auditable record of every change ever made to production - tying directly back to the Kubernetes and CI/CD lessons earlier in this curriculum.

Try it

Run these in the practice terminal (opens in a new tab). It opens in a new tab, so you keep your place here.
bash
git log --oneline --graph --decorate --all

When you're ready, hit Mark complete and move to the next lesson.

Challenge

Show a compact, one-line-per-commit graph of every branch in the repository.

Want to experiment first? Try things in the practice terminal (opens in a new tab), then enter the command that solves the task here.

Quiz

Lock in the concepts. Score at least 80% to mark the lesson complete.

0 of 2 answered

Done with this one?

Skipped the challenge? You can mark the lesson complete by hand.

Your notes

Kept on this browser only.