PromptHub
Developer Tools Git Workflow Automation

Stop Wasting Hours on Git Branches! Use Git-Town Instead

B

Bright Coding

Author

9 min read
14 views
Stop Wasting Hours on Git Branches! Use Git-Town Instead

Stop Wasting Hours on Git Branches! Use Git-Town Instead

What if every Git branch operation took 10 seconds instead of 10 minutes?

Picture this: It's 4:47 PM on a Friday. You've just finished that critical feature, and now you're staring at your terminal, mentally preparing for the Git gymnastics ahead. Sync with main. Resolve conflicts. Push. Create pull request. Delete the branch after merge. Oh, and don't forget to clean up those three stale branches from last sprint. By the time you're done, it's 5:23 PM, your brain is fried, and you've made zero forward progress on actual code.

Sound painfully familiar? You're not alone. Developers lose hours every week to repetitive Git branch management—hours that could be spent building features, fixing bugs, or actually leaving work on time. The worst part? Most of us accept this as "just how Git works." We've normalized the friction, internalized the pain, and convinced ourselves that typing git checkout main && git pull && git checkout -b feature-whatever for the thousandth time is somehow acceptable.

Here's the secret that elite engineering teams already know: it doesn't have to be this way.

Enter Git-Town — a battle-tested, open-source Git extension that's quietly revolutionizing how developers handle branches. With a single command, you can create properly structured feature branches, keep them synchronized, ship them cleanly, and eliminate the cleanup drudgery. Compatible with every major workflow from Git Flow to trunk-based development, Git-Town doesn't replace Git—it supercharges it. And once you try it, you'll wonder how you ever lived without it.

What is Git-Town?

Git-Town is an open-source command-line tool that provides additional Git commands specifically designed to automate the entire lifecycle of Git branches. Created by developers who were fed up with repetitive branch operations, Git-Town sits as a lightweight layer on top of your existing Git installation—no migration, no disruption, just pure productivity gains from day one.

The project lives at github.com/git-town/git-town and has earned its stripes in the open-source community through rigorous testing, cross-platform support, and a philosophy of workflow agnosticism. Whether your team worships at the altar of Git Flow, swears by GitHub Flow, rides the GitLab Flow wave, or pushes directly to trunk, Git-Town adapts to your conventions rather than forcing you into its own.

What makes Git-Town genuinely exciting right now is its stacked changes support—a feature that's becoming critical as more teams adopt complex branching strategies and mono-repo architectures. In an era where pull requests are getting smaller and more frequent, managing branch dependencies manually is a recipe for merge conflict hell. Git-Town's stacked change commands let you build feature branches on top of other feature branches, then seamlessly restructure, merge, or ship them independently.

The tool is written in Go, ensuring blazing-fast performance and native binaries across macOS, Linux, and Windows. Its active development shows in the comprehensive test suite—end-to-end tests, unit tests, linter checks, and dedicated Windows validation all run continuously via GitHub Actions. This isn't a hobby project; it's production infrastructure that teams rely on daily.

Key Features That Transform Your Workflow

Git-Town's command set is organized into logical groups that mirror how developers actually work. Here's what makes each category indispensable:

Basic Development Commands: Your Daily Driver

  • git town hack — Creates a new feature branch that's already up-to-date with main. No more git checkout main && git pull && git checkout -b ... incantations. One word, perfect branch.
  • git town sync — The crown jewel. Updates your current branch with changes from its parent, pulls updates, pushes your work, and automatically removes branches that have already been shipped. This single command eliminates an entire category of "wait, did I delete that already?" confusion.
  • git town switch — A text-based UI for jumping between branches. Forget git branch | grep pipe gymnastics; this is fuzzy-finding for your branch list.
  • git town propose — Creates pull or merge requests directly from the CLI, bridging the gap between your terminal and your Git forge.

Stacked Changes: The Secret Weapon

This is where Git-Town separates itself from every other Git helper:

  • git town append — Insert a new branch as a child of your current branch, maintaining stack relationships automatically.
  • git town prepend — Slip a new branch between your current branch and its parent—perfect for when you realize you need an intermediate refactoring step.
  • git town set-parent — Rebase your branch onto a different parent without the manual git rebase --onto headache.
  • git town swap — Exchange positions with your parent branch in the stack. Need to reorder your PR chain? Done.
  • git town merge — Combine two adjacent stacked branches into one, cleaning up your history.
  • git town detach — Extract a branch from a stack, making it independent.

Smart Branch Syncing Controls

Not every branch should behave the same way:

  • git town contribute — Add commits to someone else's feature branch without claiming ownership.
  • git town observe — Track a colleague's branch locally without your changes affecting it.
  • git town park — Temporarily stop syncing a branch—ideal for long-running experiments.
  • git town prototype — Sync locally but don't push, keeping work private until ready.

Error Recovery That Actually Works

Git-Town remembers what it was doing:

  • git town continue — Resume after resolving merge conflicts.
  • git town undo — Revert the most recent Git-Town command completely.
  • git town skip — Bypass the current branch and keep going.
  • git town status — See exactly where a suspended operation stands.

Real-World Use Cases Where Git-Town Shines

Use Case 1: The Solo Developer Shipping Faster

You're a freelancer juggling three client projects. Each morning starts with the same ritual: pull updates, check what's changed, figure out which branches are stale. With Git-Town, git town sync becomes your morning coffee companion—one command, all branches updated, shipped ones vanished. The mental overhead of branch bookkeeping simply disappears.

Use Case 2: Stacked PRs for Code Review Quality

Your team wants smaller, focused pull requests, but features have natural dependencies. You build the authentication refactor (PR #1), then the user dashboard that uses it (PR #2), then the admin panel extension (PR #3). Without Git-Town, rebasing PR #2 after PR #1 gets feedback is a nightmare. With git town append, git town prepend, and git town set-parent, your stack stays coherent even as requirements shift. Reviewers get digestible chunks; you get maintainable history.

Use Case 3: Mono-Repo Branch Hygiene

In a mono-repo with dozens of active developers, branch proliferation is real. Hundreds of stale branches accumulate, CI resources burn on abandoned work, and git branch -a output becomes unreadable. Git-Town's automatic cleanup during sync, combined with git town delete for explicit removal, keeps your repository lean. The git town branch command visualizes your local hierarchy, making navigation intuitive even at scale.

Use Case 4: Team Onboarding and Consistency

New hires struggle with "how we do Git here." Git-Town's git town init provides a visual setup assistant that encodes your team's conventions into configuration. Once set up, everyone uses the same commands with the same behavior. The git town config command exposes settings explicitly, turning tribal knowledge into documented, version-controllable practice.

Step-by-Step Installation & Setup Guide

Getting started with Git-Town takes under five minutes. Here's the complete path from zero to automated branches.

macOS Installation

The Homebrew tap provides the smoothest experience:

# Add the Git-Town tap and install
brew install git-town

# Verify installation
git town --version

Linux Installation

Download the latest release binary directly:

# Download latest release (adjust version as needed)
curl -LO https://github.com/git-town/git-town/releases/latest/download/git-town_linux_intel_64
debug

# Make executable and move to PATH
chmod +x git-town_linux_intel_64
sudo mv git-town_linux_intel_64 /usr/local/bin/git-town

# Verify
git town --version

For Arch Linux users, it's available in the AUR as git-town.

Windows Installation

Use Scoop for easy management:

# Add the bucket and install
scoop bucket add git-town https://github.com/git-town/scoop-bucket.git
scoop install git-town

# Or download the Windows executable from GitHub releases

Initial Configuration

Once installed, run the interactive setup:

# Launch the visual configuration assistant
git town init

This walks you through:

  • Your main branch name (typically main or master)
  • Your perennial branches (long-lived branches like production, staging)
  • Your default branch type for new features
  • Pull request hosting configuration (GitHub, GitLab, Gitea, etc.)

For manual configuration or CI environments:

# View current configuration
git town config

# Set main branch explicitly
git config git-town.main-branch main

# Add a perennial branch
git town config perennial-branches add staging

# Enable offline mode for air-gapped environments
git town offline true

Shell Completions (Optional but Recommended)

# Bash - add to ~/.bashrc
git town completions bash > /etc/bash_completion.d/git-town

# Zsh - add to your fpath
git town completions zsh > "${fpath[1]}/_git-town"

# Fish
git town completions fish > ~/.config/fish/completions/git-town.fish

REAL Code Examples from Git-Town

Let's examine actual patterns from the Git-Town repository and documentation, with detailed explanations of what's happening under the hood.

Example 1: The Classic Hack-Sync-Ship Cycle

This is the bread-and-butter workflow that converts Git-Town skeptics into evangelists:

# Create a new feature branch, already up-to-date with main
git town hack user-authentication-refactor

# Git-Town executes internally:
# 1. git checkout main
# 2. git pull  (fetch latest, fast-forward if possible)
# 3. git checkout -b user-authentication-refactor
# 4. git push -u origin user-authentication-refactor (if configured)

# ... do your work, make commits ...

# Synchronize with ongoing changes elsewhere
git town sync

# Git-Town's sync logic:
# 1. Fetch updates from origin
# 2. Pull updates for the current branch's parent (main)
# 3. Merge or rebase parent into current branch (configurable)
# 4. Push current branch to origin
# 5. Prune branches whose tracking branches are gone (shipped!)

# When ready to deliver
git town ship

# Git-Town ships by:
# 1. Ensuring the branch is fully synced
# 2. Merging into main via your preferred strategy (merge, squash, rebase)
# 3. Pushing main to origin
# 4. Deleting the local and remote feature branch
# 5. Checking out main

Why this matters: The traditional approach requires remembering six discrete Git operations, executed in the correct order, with error handling at each step. Git-Town compresses this into three memorable commands with built-in safety checks.

Example 2: Building a Stack of Dependent Changes

Stacked changes are where Git-Town's power truly becomes apparent. Here's how to build a three-level feature stack:

# Start from main, build the foundation
git town hack api-rate-limiting

# ... implement rate limiting ...

# Add a consumer that depends on the rate limiting
git town append dashboard-usage-widget

# Git-Town records the parent relationship:
# dashboard-usage-widget's parent = api-rate-limiting
# This metadata lives in Git notes / configuration

# ... build the widget ...

# Add another layer: admin controls for the widget
git town append admin-rate-override

# Branch hierarchy now:
# main <- api-rate-limiting <- dashboard-usage-widget <- admin-rate-override

# Later, you get feedback that dashboard-usage-widget needs refactoring
# before admin-rate-override can proceed. Swap their order:
git town swap

# Now: main <- api-rate-limiting <- admin-rate-override <- dashboard-usage-widget
# (Note: this intelligently handles commit replaying to maintain logical history)

# When api-rate-limiting ships, sync propagates changes through the stack:
git town sync

# Git-Town updates each branch in dependency order,
# handling the rebase cascade automatically

The hidden complexity handled here: Manual stacked rebasing requires tracking which branch depends on which, computing correct --onto parameters, and recovering gracefully when intermediate commits change. Git-Town's parent metadata makes this deterministic and reversible.

Example 3: Selective Sync with Branch States

Not all branches should sync identically. Git-Town's state commands enable sophisticated workflows:

# You're reviewing a colleague's branch but don't want to push your test changes
git town observe teammate-experimental-search

# Now sync will:
# - Pull their updates
# - NEVER push your local changes to origin
# - Maintain the branch for local experimentation

# You have a long-running spike that shouldn't sync yet
git town park personal-refactoring-ideas

# This branch is now excluded from all sync operations
# until you explicitly unpark it

# You want to contribute fixes to someone's PR without taking ownership
git town contribute hotfix-memory-leak

# Your commits will be pushed, but Git-Town knows this isn't "your" branch
# for shipping purposes

# Check the current state of all branches
git town status

# Shows suspended operations, parked branches, observed branches,
# and any in-progress Git-Town command that needs continue/abort

These states solve real coordination problems: Traditional Git has no concept of "I'm looking but not touching" or "this is my sandbox." Git-Town's state machine formalizes these patterns, preventing accidental pushes and making team workflows explicit.

Example 4: Recovery from the Inevitable Merge Conflict

Even with automation, conflicts happen. Git-Town's recovery commands shine here:

# During a sync, you hit a conflict in package.json
git town sync
# ... conflict markers appear ...

# Resolve the conflict manually (edit files, git add)

# Resume exactly where Git-Town left off
git town continue

# Git-Town remembers:
# - Which command was running (sync)
# - Which branch was being processed
# - Which step in the sync sequence (pull, merge, push?)
# - And continues from the correct point

# Or if you realize you've made a mess and want to start over:
git town undo

# This reverses ALL changes made by the last Git-Town command,
# including branch checkouts, merges, and pushes when possible

# See what happened recently for debugging:
git town runlog

# Displays the repository state before and after recent Git-Town operations,
# invaluable for understanding unexpected behavior

Advanced Usage & Best Practices

Master the sync cadence. Run git town sync at natural breakpoints—morning start, before pushing, after code review feedback. The automatic pruning of shipped branches only happens during sync, so regular syncs keep your repository clean.

Configure your ship strategy explicitly. Git-Town supports multiple merge strategies. Set this per-project to match team conventions:

# For teams requiring linear history
git config git-town.ship-strategy rebase

# For teams wanting clean single-commit features
git config git-town.ship-strategy squash

# For teams preserving merge commits
git config git-town.ship-strategy merge

Use compress before shipping complex features. The git town compress command squashes all commits on a feature branch to a single commit—ideal when your development history is messy but the final diff is what matters for review.

Leverage offline mode for travel or spotty connectivity:

git town offline true
# Now all operations work locally without network calls
# Perfect for flights, trains, or coffee shop coding

Integrate with Git hooks. Git-Town respects your existing hooks and adds its own hook points for custom validation. Validate branch naming conventions, require ticket references, or trigger CI pre-checks.

Git-Town vs. Alternatives: Why Make the Switch?

Feature Git-Town Git Flow CLI Hub LazyGit Raw Git
Stacked changes support ✅ Native, full command set ❌ None ❌ None ⚠️ Manual ❌ None
Workflow agnostic ✅ All major workflows ❌ Git Flow only ⚠️ GitHub-centric ✅ Flexible ✅ N/A
Automatic branch cleanup ✅ Built into sync ❌ Manual ❌ Manual ❌ Manual ❌ Manual
Error recovery (continue/undo) ✅ Sophisticated state machine ❌ None ❌ None ❌ None ❌ None
Mono-repo optimization ✅ Designed for scale ⚠️ Basic ❌ No ⚠️ Basic ❌ No
Cross-platform ✅ Native binaries ✅ Yes ✅ Yes ✅ Yes ✅ Yes
PR creation from CLI propose command ❌ None ✅ Yes ⚠️ Limited ❌ None
Offline operation ✅ Explicit mode ❌ No ❌ No ✅ Yes ✅ Yes

The decisive difference: Other tools optimize individual Git operations; Git-Town optimizes the entire branch lifecycle. Where hub excels at GitHub-specific interactions and LazyGit provides a TUI for raw Git, Git-Town introduces semantic commands that understand why you're branching, not just how.

FAQ: Developer Concerns Addressed

Q: Does Git-Town modify my existing Git installation or repositories?

No. Git-Town operates as a separate binary that wraps Git commands. It stores metadata in Git's own configuration system and notes. Uninstalling Git-Town leaves your repository in a standard Git state—though you'll miss the automation immediately.

Q: Can I use Git-Town with my team's existing workflow?

Absolutely. Git-Town is explicitly designed for workflow compatibility. Configure your main branch, perennial branches, and ship strategy to match your conventions. Teams using Git Flow, GitHub Flow, GitLab Flow, or trunk-based development all report success.

Q: What happens if Git-Town encounters a merge conflict?

Git-Town pauses gracefully, presents the conflict markers, and waits. Resolve conflicts normally with git add, then run git town continue to resume exactly where the automation left off. No lost work, no repeated steps.

Q: Is Git-Town suitable for large mono-repos?

Yes, this is a core design target. The observe and park commands let you manage hundreds of branches selectively. The branch command visualizes hierarchy. Sync operations are optimized to avoid unnecessary fetches.

Q: How does Git-Town handle code review requirements?

Git-Town integrates with pull request workflows rather than replacing them. The propose command creates PRs/MRs from your terminal. The ship command can be configured to require PR merge, or you can ship directly for hotfixes.

Q: Can I mix Git-Town commands with regular Git commands?

Yes, freely. Git-Town doesn't lock you in. Many developers use Git-Town for branch lifecycle operations (hack, sync, ship) while using raw Git for granular operations (git log, git diff, interactive rebase).

Q: What's the performance impact?

Negligible. Written in Go with native binaries, Git-Town adds milliseconds of overhead to wrap Git commands. The time saved in reduced typing and eliminated mistakes far outweighs any runtime cost.

Conclusion: Reclaim Your Development Flow

Git branch management is the silent productivity killer that developers have normalized for too long. We've accepted friction as fate, complexity as character-building, and repetitive manual operations as "just part of the job." But excellence in engineering means eliminating toil—not enduring it.

Git-Town represents a fundamental shift: from remembering Git incantations to expressing intent. From fragile manual sequences to robust automated workflows. From branch chaos to structured, navigable history. The commands are intuitive, the recovery paths are safe, and the stacked changes support opens possibilities that raw Git simply cannot offer cleanly.

The teams shipping fastest aren't working harder—they're working smarter with tools that respect their time. Git-Town is that tool for Git workflows.

Your next step is simple: Head to github.com/git-town/git-town, install it in your next repository, and run git town hack for your next feature. Give it one sprint. Track how many minutes you save, how many errors you avoid, how much mental energy you reclaim. Then ask yourself: why did I wait so long?

Star the repository, open an issue if you hit edge cases, and join the growing community of developers who've stopped fighting their tools—and started shipping with them.

Comments (0)

Comments are moderated before appearing.

No comments yet. Be the first to share your thoughts!

Support us! ☕