888 words
4 minutes

Git Branches - How to Not Break Prod and Stay Alive

By · Developer Advocate · Docker Captain · IBM Champion
Close-up of a black LG monitor showing a purple-pink gradient wallpaper, a silver Mac mini beside it and an Xbox console below, with a white Magic Keyboard in the foreground on a clean white desk

Hey queens. You’re building stuff. Pushing code. Shipping features.

And then someone says:

“Just create a branch for that.”

Wait — a what?

Real talk: Git can feel like sorcery at first. Branches? Rebases? Merge commits? Upstream what?

But here’s the truth:

Branches are not scary. They’re your safety net. Your creative zone. Your undo button.

They let you try bold things without risking production.

They help teams build fast — and stay sane.

This guide breaks it down, step by step.

No buzzwords. No hand-waving. Just real Git, the way developers actually use it in 2025.

Let’s start from the core idea — what even is a branch?

What’s a Branch, Really?#

A branch is a pointer (a variable) that references a commit.

In practice, it’s a parallel version of your codebase where you can work safely — nothing affects main until you decide it’s ready.

Branches give you:

  • freedom to experiment,
  • a clean commit history,
  • protection from disaster,
  • and a solid setup for teamwork.

How to Work with Branches - Step by Step#

1. Create a New Branch and Switch to It#

Modern way (Git ≥ 2.23):

Terminal window
git switch -c feature/signup
  • switch is a modern, more readable alternative to checkout.
  • -c means “create a new branch.”

Classic way (still valid):

Terminal window
git checkout -b feature/signup

🧭 Tip: Use meaningful, kebab-case names with prefixes like: feature/signup, bugfix/fix-login, hotfix/crash-on-submit, release/v1.3.0

2. Do Some Work: Commit & Push#

Example:

Terminal window
echo "Sign-up logic" > signup.js
git add signup.js
git commit -m "Add sign-up logic"
git push -u origin feature/signup
  • -u sets the upstream branch so future git push and git pull work without arguments.

📌 After this, you can simply use git push and git pull without specifying branch names.

3. See What Branch You’re In#

Terminal window
git branch
  • The current branch is marked with a *.

To create a branch without switching:

Terminal window
git branch feature/experiment

📌 Quick jump back to the previous branch:

Terminal window
git switch -

Super handy when jumping between main and a feature branch.

4. Switch Back to main and Update It#

Terminal window
git switch main
git pull --ff-only origin main

🧭 Important:

  • Run this from the main branch.
  • If you have local commits, Git will stop politely — preventing accidental overwrites.

5. Merge Your Branch into main#

Standard merge:

Terminal window
git merge feature/signup

If main hasn’t changed since you branched off, Git performs a fast-forward — just moves the pointer.

Want to preserve a visible merge commit?

Terminal window
git merge --no-ff feature/signup

🧭 Great for tracking feature branches in project history or pull requests.

6. Handling Merge Conflicts#

If Git reports a conflict:

  1. Open the file and look for:

    <<<<<<< HEAD
    code from main
    =======
    code from your branch
    >>>>>>> feature/signup
  2. Manually fix the file.

  3. Stage the resolved file:

    Terminal window
    git add filename
  4. If a real merge happened (not fast-forward), finish with:

    Terminal window
    git commit

💡 If it was fast-forward, Git already did everything — no commit needed.

7. Delete the Branch#

Locally:

Terminal window
git branch -d feature/signup

If the branch hasn’t been merged yet, use:

Terminal window
git branch -D feature/signup

Remotely:

Terminal window
git push origin --delete feature/signup

📌 An alternative is:

Terminal window
git push origin :feature/signup

—but it’s less readable.

8. View Branch History Visually#

Terminal window
git log --oneline --graph --decorate --all

This shows your full commit tree, across all branches — clean and visual.

Merge vs Rebase: When and Why#

  • merge preserves full history and creates a merge commit.
  • rebase rewrites your branch history to make it look like you started from the latest main.

To rebase:

Terminal window
git fetch origin
git rebase origin/main

🧭 Only rebase private branches.

If someone else has pulled your branch — do not rebase unless the team agrees.

If you must force-push after a rebase, never use --force directly. Use:

Terminal window
git push --force-with-lease

✅ This makes Git check that nobody has pushed since your last pull — safer for teams.

Suggested Team Workflow#

  1. Start a feature branch from main:

    Terminal window
    git switch -c feature/add-login
  2. Work, commit, push:

    Terminal window
    git push -u origin feature/add-login
  3. Open a pull request on GitHub/GitLab for review and CI checks.

  4. Once approved, merge it — ideally with --no-ff.

  5. Delete the branch locally and on the remote.

  6. Keep main clean and always production-ready.

Working with Remotes#

TaskCommand
Push and set upstreamgit push -u origin feature/branch
Pull updates with rebasegit pull --rebase origin main
Delete branch on remotegit push origin --delete feature/branch
Clean up remote branch refsgit fetch --prune or git remote prune origin
Safe force-push after rebasegit push --force-with-lease

📌 Make pruning automatic:

Terminal window
git config --global fetch.prune true

📌 Make rebase your default pull strategy:

Terminal window
git config --global pull.rebase true

Or do it manually per pull:

Terminal window
git pull --rebase

Keeps your history linear and avoids noisy merge commits.

Command Cheat Sheet#

ActionCommand
Create + switch to new branchgit switch -c feature/branch
Switch branchesgit switch branch-name
Create branch without switchinggit branch branch-name
See all branchesgit branch
Jump to previous branchgit switch -
Update main before mergegit switch main && git pull --ff-only origin main
Merge branchgit merge feature/branch
Merge with visible historygit merge --no-ff feature/branch
Rebase feature onto latest maingit rebase origin/main
Delete local branchgit branch -d branch-name or -D
Delete remote branchgit push origin --delete branch-name
Visualize all historygit log --oneline --graph --decorate --all
Safe force-push after rebasegit push --force-with-lease
Clean deleted remotes automaticallygit config --global fetch.prune true
Use rebase by default on pullgit config --global pull.rebase true

Best Practices (And Why They Matter)#

  • One branch per task
    Keeps changes isolated, focused, and easy to review.

  • Use clear, consistent naming
    Prefixes like feature/, fix/, release/ help.
    Use lowercase + hyphens: feature/add-login.

  • Use pull requests
    Code reviews, CI checks, and visibility improve code quality.

  • Avoid --force — use --force-with-lease
    Don’t overwrite others’ work by mistake.

  • Clean up your branches
    Remove them when they’re done — both locally and on remote.

  • Only rebase private branches
    Never rewrite history others rely on.

Final Thoughts#

Git branches aren’t just a tool — they’re a mindset.

They give you a safe space to build, break, and experiment — without breaking production.

With branches, you can:

  • isolate ideas,
  • collaborate without chaos,
  • and build with confidence.

Branch = creativity
Main = stability
You = the developer who keeps both in harmony.


Tatiana Mikhaleva

Docker Captain  ·  IBM Champion  ·  AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

Related Posts

Same category
  1. 1
    How to Secure AI Agents in Production: IBM's Six-Phase Framework
    DevOps & Cloud · Teams secure AI agents like normal software, and production breaks. Here's IBM and Anthropic's six-phase framework for securing them, phase by phase.
  2. 2
    Your AI Agent Doesn't Need a Better Prompt. It Needs a Ceiling
    DevOps & Cloud · A prompt is not a security control. It's a wish. The Vault → Sentinel → MCP → ADLC → watsonx Orchestrate stack that gives AI agents a hard ceiling — and why IBM consolidating HashiCorp made the whole thing boring, in the best possible way.
  3. 3
    CNCF Q1 2026 Report — Why Feature Flagging Is the Hidden Gateway to Cloud Native Maturity
    DevOps & Cloud · CNCF Q1 2026 cloud native report analysis. Why feature flagging is the bridge from mainstream to advanced engineering practice, with exclusive commentary from the report's author.
  4. 4
    AI SRE Joined My On-Call — A Beginner-Friendly Walkthrough of Rootly
    DevOps & Cloud · What an AI SRE actually does on call. A hands-on walkthrough of Rootly — how it observes, advises, and (when you let it) acts. With a real look at the four-level trust model.

Random Posts

Random
  1. 1
    Git Merge Conflicts for Beginners - What to Do When Your Branches Have Beef
    DevOps & Cloud · Learn how to fix Git merge conflicts step-by-step. A fun, beginner-friendly guide to resolving and avoiding conflict errors in your branches.
  2. 2
    Linux for Beginners - Essential Commands Every IT Girl Must Know
    DevOps & Cloud · Master Linux commands & boost your IT skills! Learn essential commands for navigating, managing files & running processes like a pro.
  3. 3
    Kubernetes on Your Laptop — No Cloud, No Boring Docs, Just Magic
    DevOps & Cloud · Kubernetes tutorial for beginners. Learn to run a full local cluster with Docker, Minikube, YAML, Pods, Deployments, Secrets — no cloud needed.
  4. 4
    DNS for IT Girls - How the Internet Works Like Magic
    DevOps & Cloud · Learn how DNS works, from hosts files to DNS servers, caching, and troubleshooting. This IT-girl guide makes networking easy, fun, and beginner-friendly!
Git Branches - How to Not Break Prod and Stay Alive
https://devops.pink/git-branches-how-to-not-break-prod-and-stay-alive/
Author
Tatiana Mikhaleva
Published
2025-06-16
License
CC BY-NC-SA 4.0