Skip to main content

Real-world use cases

Summary: Git is not just a lone developer's tool. It structures four major scenarios of software life: the personal project, the internal team, the open-source contribution, and the DevOps / CI-CD pipeline. This lesson gives a concrete example of each.

Case 1 · The personal project (solo mode)​

You are building a small tool for yourself — a script, a portfolio site, a game.

What Git brings, even alone:

  • The confidence to experiment ("I can always go back").
  • A record of why each decision was made, useful 6 months later when you reopen the project and remember nothing.
  • A free online backup through GitHub/GitLab, in one push.

Verdict: even without a team, Git is basic development hygiene.

Case 2 · The internal team (collaboration mode)​

You join an 8-person startup. Three developers touch the code every day.

The team's golden rule: the main branch is always in a deployable state. Nobody touches it directly. Every change goes through a branch + a pull request + a review.

What this workflow brings:

  • Code only reaches production after peer review.
  • Every decision is discussed in writing in the pull request — precious for onboarding newcomers.
  • Failed experiments (like Chloe's branch) impact nobody. They are thrown away, no regrets.

Case 3 · The open-source contribution​

You want to fix a typo in the FastAPI documentation, or propose an improvement to Docusaurus. You are not on the team. How does it work?

This workflow, called fork-and-pull-request, is the foundation of all modern open source. It is what lets strangers, all over the world, contribute to Linux, Kubernetes, Python, React, Node.js…

Why it is possible:

  • Git is distributed: your fork contains the entire history, no special permission needed.
  • The pull request provides a discussion framework before integration.
  • The project's maintainer keeps final control over what gets merged.

It is an exceptional reputation machine: every accepted pull request becomes a visible line in your GitHub profile, checked by recruiters.

Case 4 · The DevOps / CI-CD pipeline​

This is where Git reveals its true power: in the modern world, every git push can trigger an entire automation chain.

Key points to remember:

  • A simple git push triggers everything else. Git is the pipeline's entry gate.
  • A failing test blocks the deployment — that is what makes the process reliable.
  • A deployment can be fully automatic (full CD mode) or require human approval (staging → production on sign-off).

This is the foundation of modern DevOps. Without Git, none of this automation would be possible.

GitOps · When Git becomes the single source of truth​

There is an even more recent practice, called GitOps, where the entire infrastructure (servers, networks, Kubernetes configurations) is described in Git files. A change in a YAML file automatically triggers reprovisioning.

The GitOps slogan: "If it is not in Git, it does not exist."

Translation: no more hidden manual changes, no more "it worked last week, nobody knows why it is broken". Git is the single point of truth — and therefore the only place to audit during an incident.

You will meet GitOps in depth in the Argo CD and Flux CD courses of our premium path.

Summary: the 4 worlds of Git​

Remember in 30 seconds​

  • Solo: Git is hygiene — history + backup + traceability of the why.
  • Team: the main branch is sacred, everything goes through branch + pull request.
  • Open source: the fork + pull request workflow is what lets strangers contribute to Linux, Python, React…
  • DevOps: a simple git push triggers tests, quality, security and deployment. Git is the pipeline's entry gate.
  • GitOps: the infrastructure itself lives in Git. "If it is not in Git, it does not exist."

Next: Recap and FAQ →