How Big Companies Like Google & Netflix Use Git Tags in Production

If you think Git is just about commit, push, and pull, you’re missing one of its most powerful features: Git tags.

For companies like Google and Netflix, Git tags are not optional. They’re a safety line that protects millions of users from bad releases, broken features, and messy rollbacks.

In this post, we’ll break down:

• What a Git tag is (in simple terms)
• How Google uses tags with trunk-based development
• How Netflix links tags to Docker and Kubernetes
• Practical Git techniques you can copy for your own team

All explained without jargon.

What Is a Git Tag? (Simple Definition)

Let’s start with the basics.

A Git tag is a permanent label attached to a specific commit.

Think of it like putting a “FINAL VERSION” sticker on one exact point in your code history.

• Commits are like saved steps.
• A tag marks one special step as important — usually a release version.

Example:

git tag -a v1.0.0 -m "First production release"
git push origin v1.0.0

Now:

• v1.0.0 always points to the same code, forever.
• Your CI/CD system can deploy that exact version.
• You can roll back to it at any time.

This “frozen in time” nature is why big companies trust tags for production.

The Golden Rule of Big Tech Git

Most large engineering organizations follow a simple rule:

Don’t deploy from a branch
Always deploy from a Git tag

Why?

• Branches move (new commits, merges, rebases)
• Tags don’t move (they always point to the same commit)

In production, stability and traceability matter. Tags provide both.

How Google Uses Git Tags at Massive Scale

Google is famous for its monorepo—a huge repository where the majority of its code lives. Thousands of developers work in it daily.

To make this manageable, Google uses a mix of:

• Trunk-based development
• Strict code review
• Automated testing
• Tag-based releases

1. Trunk-Based Development

At Google, most work happens off a central mainline or “trunk”.

• Developers create small, short-lived branches
• They make focused changes
• After code review + tests, they merge back quickly

No long-lived feature branches drifting away for months.

This keeps:

• The main branch always close to “release-ready”
• Merges small and easy to reason about
• Teams aligned on a single, shared view of the code

2. Tag-Based Releases

When a build is ready to be released, Google’s systems create a release tag.

Example (simplified):

release-2025-03-15-1432

That tag represents:

• One specific commit in the monorepo
• That passed tests and checks
• That is now being deployed to users

Tags allow Google to:

• Know exactly which code is running in production
• Quickly rollback to a previous tag if something goes wrong
• Provide clear references for audits and incident reports

3. Canary Releases with Tags

Google often does canary rollouts:

1. Deploy the new tagged version to a small percentage of users
2. Monitor errors and performance
3. If everything looks good → roll out to everyone

If there’s a problem:

• They stop the rollout
• Redeploy an older, stable tag

Tags are the anchor that makes all this safe and repeatable.

How Netflix Uses Git Tags in a Microservices World

Where Google runs a massive monorepo, Netflix runs hundreds of microservices.

Each service has:

• Its own repo
• Its own pipeline
• Its own release tags

But the core idea is the same: tags = production truth.

1. From Git Tag to Docker Tag

For a service like user-service, Netflix follows a chain like this:

Git Tag → Docker Image → Kubernetes Deployment

Example:

git tag -a v2.7.4 -m "User service release"
git push origin v2.7.4

From there:

• CI/CD builds: user-service:v2.7.4
• This Docker image is deployed to Kubernetes
• That version serves real users

Now everything lines up:

• Git tag: v2.7.4
• Docker image: user-service:v2.7.4
• Production: running v2.7.4

This 1:1 mapping makes debugging, logging, and audits much easier.

2. Instant Rollback via Tags

If v2.7.4 introduces a bug in production, Netflix doesn’t panic.

They already have v2.7.3:

v2.7.4  (buggy)
v2.7.3  (stable)

Rollback is as simple as:

• Redeploy the old image (user-service:v2.7.3)
• Or instruct Kubernetes to use the previous version

Because images and deployments are tied to Git tags, there’s zero guesswork.

3. Hotfixes on Top of Tags

For critical bugs:

1. Checkout the last released tag: git checkout v2.7.4
2. Create a hotfix branch
3. Fix the issue
4. Tag the new release: git tag -a v2.7.5 -m "Hotfix for user-service" git push origin v2.7.5
5. CI/CD builds and deploys v2.7.5

This process ensures:

• Only the fix goes to production
• Unfinished features on main don’t accidentally sneak in

Other Git Techniques Big Companies Combine with Tags

Git tags don’t work alone. They’re part of a larger culture of safe delivery.

Here are other Git practices you’ll see at Google, Netflix, and similar companies.

1. Mandatory Code Review

No one pushes directly to main or trunk.

Every change must be:

• Reviewed by at least one other engineer
• Often tied to a ticket or issue
• Verified by automated checks

This prevents low-quality or dangerous changes from reaching production.

2. Continuous Integration (CI)

Every push triggers:

Build → Test → Analyze → Report

If tests fail, merges are blocked. This keeps the main branch always green and close to deployable.

3. Feature Flags Instead of Long Branches

Rather than long-lived branches, big companies use feature flags:

• Code is merged behind a flag
• The feature can be turned ON/OFF at runtime
• No risky branch merges at the last minute

This pairs beautifully with tags:

• The tag defines which code is in production
• Feature flags define which behavior is active

4. Strict Access Control

Who can:

• Create tags?
• Approve merges?
• Trigger deployments?

In big companies, the answers are carefully controlled. Typically:

• Developers propose changes
• Automation merges, tags, and deploys
• Direct manual deployment is rare and restricted

How You Can Apply These Ideas in Your Own Projects

You don’t need Google’s monorepo or Netflix’s scale to start using these techniques.

Here’s a simple Git workflow you can adopt today:

1. Use one main branch (main or trunk)
2. Develop on short-lived feature branches
3. Require at least one code review
4. Set up CI to run tests on every push
5. Before deploying: git tag -a v1.0.0 -m "Production release" git push origin v1.0.0
6. Configure your CI/CD to deploy only from tags
7. Use tags to roll back if something goes wrong

Final Thoughts

Big companies don’t treat Git as just a source control tool.
They treat it as a safety and reliability system.

• Git tags mark the exact code running in production
• Branches are for work in progress
• Automation and reviews keep the main branch clean
• Feature flags and canary releases let them deliver safely

You might not be Google or Netflix (yet), but you can absolutely borrow their Git discipline.

Start small. Start with tags.
Your future self—and your users—will thank you.

Master Git Grab From Amazon