The problem worktrees solve

You are deep in a feature branch when an urgent bug report lands. Stash, switch, fix, switch back, pop the stash - context lost, half a coffee gone. Worktrees let you check out multiple branches simultaneously, in different directories, sharing the same .git.

Aliases that pay rent

The first ten Git aliases everyone reaches for cover the basics: st, co, br, ci. The next layer is where productivity really compounds - aliases for the multi-step workflows you do dozens of times per day. This collection focuses on those.

Stop, breathe, do not push

The first rule of Git disasters: do not make it worse. Most "disasters" are recoverable because Git is conservative - it rarely deletes data, it just stops referencing it. The reflog and dangling objects are your friends.

Snapshot before recovery

Before attempting fixes, save the current state:

git tag panic-snapshot
cp -r .git ~/git-backup-$(date +%s)

You can always return to this point if recovery goes sideways.

Why binaries are hard

Git's storage model is designed for text. Each commit stores complete object snapshots (deduplicated by content hash). Text files compress and delta well; binaries usually do not. Edit a 50 MB image once and you have added 50 MB to the repo. Edit it ten times and history is nearly half a gigabyte.

Diff and merge

Git cannot diff binaries by default. Marking a file as binary in .gitattributes makes that explicit:

Git is not just for code

Git tracks any text file: Markdown, AsciiDoc, LaTeX, plain prose. Writers, documentation teams, and academics use Git for the same reasons developers do - history, branches, parallel drafts, and merge resolution. The terminology takes some unlearning, but the workflow benefits are real.

Why fork

You rarely have write access to a project you want to contribute to. The forking workflow solves this: you fork the upstream repo into your own namespace, push to your fork, and open pull requests from your fork to the upstream. It is the default model for almost every public OSS project.

The simplest workflow that works

GitHub Flow is a pragmatic, lightweight model: main is always deployable; everything else is a short-lived branch behind a pull request. It is what the GitHub team itself uses and what most open-source projects converge on.

The model

Trunk-based development (TBD) keeps a single long-lived branch - the trunk, usually main - and integrates everything frequently, ideally many times per day. Feature branches, if used at all, live for hours, not weeks. The DORA research consistently links TBD to high-performing engineering organisations.

What Git Flow is

Git Flow is a branching model proposed by Vincent Driessen in 2010. It defines five branch types - main, develop, feature/*, release/*, hotfix/* - and rules for how they interact. It suits products with explicit release cycles and parallel maintenance of older versions.

The eternal debate

A monorepo holds many projects in one repository; multi-repo splits them. Both ship products at scale - Google and Meta favour mono, Amazon and Netflix favour multi. The "right" answer depends on team size, tooling investment, and integration patterns.