Post

Improving Daily Git Workflow with Stacked Git (StGit)

Enhance your daily Git workflow with Stacked Git (StGit) for better commit management and productivity.

Improving Daily Git Workflow with Stacked Git (StGit)

Stop fighting commits. Start stacking ideas.

Most Git workflows are optimized for sharing code, not for thinking while coding. That mismatch is the root cause of messy commits, endless rebases, and painful code reviews.

This article introduces Stacked Git (StGit) — a patch-stack–based workflow that dramatically improves day-to-day development productivity while staying fully compatible with Git.


The Core Problem with Traditional Git Workflow

Git commits are immutable history units. But during development, our work is:

  • non-linear
  • exploratory
  • frequently reordered
  • revised many times before review

Typical pain points

  • “I should have refactored first”
  • “This commit mixes 3 unrelated changes”
  • “Reviewer wants a small change in commit #3”
  • “I need to temporarily remove this change to debug”

What Git forces you to do

  • Interactive rebase
  • Stashing
  • Resetting
  • Commit squashing
  • Mental gymnastics

Git is doing its job — we’re using it for the wrong phase.


The Key Insight: Commits ≠ Ideas

During development:

  • You think in ideas
  • Git stores commits

These are not the same thing.


Enter Stacked Git (StGit)

StGit introduces a lightweight abstraction on top of Git:

Patches, arranged as a stack

Each patch represents one logical idea.

You:

  • work in patches
  • reorder patches
  • edit patches
  • temporarily disable patches

Only when ready do you convert patches into Git commits.


Mental Model: Git vs StGit

Traditional Git

1
A --- B --- C --- D   (commits are fixed)

Reordering or editing history requires rewriting everything after the change.


Stacked Git

1
2
3
4
5
Base commit
   │
   ├─ Patch: refactor
   ├─ Patch: feature
   ├─ Patch: tests

Patches are:

  • movable
  • editable
  • independently applied

Git commits are generated later.


Under the Hood: What StGit Actually Does

StGit:

  • stores patches as metadata
  • applies them on top of a Git branch
  • keeps Git history clean and linear

You are not replacing Git — you are adding a layer for development ergonomics.


Initial Setup

1
stg init

This enables StGit on the current branch.

Check status:

1
stg series

Basic Daily Workflow

1. Start a new logical change

1
stg new refactor-api

Make changes, then record them:

1
stg refresh

Think of stg refresh as “update this patch”.


2. Stack another idea on top

1
stg new add-endpoint
1
stg refresh

Add tests:

1
2
stg new tests
stg refresh

View the stack:

1
stg series
1
2
3
+ refactor-api
+ add-endpoint
+ tests

Each line is one clean, reviewable idea.


Reordering Work (Without Rebase Hell)

Real life happens:

“That refactor should have happened first.”

With Git: interactive rebase. With StGit:

1
stg float refactor-api

That’s it.

Conceptual diagram

1
2
3
4
5
6
7
8
9
Before:
  refactor
  feature
  tests

After float:
  refactor
  feature
  tests

The stack adjusts safely, automatically.


Temporarily Removing a Change (Debugging Superpower)

Suspect a patch causes a bug?

1
stg pop add-endpoint

Bug gone? Confirmed.

Restore it:

1
stg push add-endpoint

No stash. No branch. No reset.


Fixing Reviewer Comments (Surgically)

Reviewer says:

“Please change validation logic.”

That logic lives in add-endpoint.

1
2
3
stg goto add-endpoint
# edit code
stg refresh

Everything above re-applies automatically.

This is where StGit shines.


Switching Tasks Without Branch Explosion

Mid-feature, urgent bug appears.

1
2
3
stg pop feature-x
stg new hotfix-null-check
stg refresh

Export just the fix:

1
stg export --commit hotfix-null-check

Resume work:

1
2
stg pop hotfix-null-check
stg push feature-x

From Patches to Git Commits

When ready to share:

Export patches as commits

1
stg export --commit

Each patch becomes one Git commit.


Squash selectively

1
stg squash refactor-api add-endpoint

Perfect for clean PRs.


Visual Summary: Development vs Sharing

1
2
3
4
5
Development phase:
  [patch][patch][patch]

Sharing phase:
  [commit][commit]

StGit optimizes development. Git optimizes distribution.

Use both for what they’re best at.


1
2
3
4
5
git config --global alias.ss "!stg series"
git config --global alias.sn "!stg new"
git config --global alias.sr "!stg refresh"
git config --global alias.sp "!stg pop"
git config --global alias.spu "!stg push"

Now StGit feels native:

1
2
3
git sn feature-x
git sr
git ss

When StGit Is Especially Valuable

  • Long-lived feature branches
  • Heavy refactors
  • Frequent review iteration
  • Context switching
  • Senior engineers who care about clean history

Final Takeaway

Git commits are for history. StGit patches are for thinking.

Once you separate those concerns, your workflow becomes:

  • calmer
  • cleaner
  • faster

And code reviews become a joy instead of a negotiation.

This post is licensed under CC BY 4.0 by the author.