943 words
5 minutes

Git Branches - How to Not Break Prod and Stay Alive

Visual DX: Git Branches - How to Not Break Prod and Stay Alive

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

And then someone says:

“Just create a branch for that.”

Wait — a what?

Let’s be real. 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.


VERDICT & AESTHETICS#

  • Visual Doctrine: Traditional DevRel creates noise. I engineer clarity, proving that deep infrastructure and an unapologetically pink aesthetic belong in the same boardroom. Deploy like a queen. Study the architecture on YouTube.
  • The Syndicate: Stop fighting your deployments alone. Gain access to zero-friction protocols, enterprise subsidies, and the DevOps Army. Enter the Discord Ecosystem.

Tatiana Mikhaleva

Principal Developer Advocate  ·  Docker Captain  ·  IBM Champion  ·  AWS Community Builder

Git Branches - How to Not Break Prod and Stay Alive
https://devops.pink/git-branches-how-to-not-break-prod-and-stay-alive/
Architect
Tatiana Mikhaleva
Issued
2025-06-16
Protocol
CC BY-NC-SA 4.0