Branches in Motion: Worktrees, Stacks, and Collaboration

Lazygit treats branch work as more than choosing a name from a list. This chapter examines how it keeps parallel change streams visible through worktrees and stacked branches, then follows a branch from local checkout to upstream synchronization, pull requests, and remote effects. The practical goal is to choose the right carrier for unfinished work and to know when a local Git action has become a collaboration decision.

The problem appears when one large branch begins to carry several kinds of work. A preparatory refactoring may be needed before a backend change, which in turn supports a frontend change. At the same time, a reviewer may be looking at one part of the work while another part needs experimentation. Stashing everything whenever attention shifts hides the relationship between the changes. A temporary WIP commit preserves the files but can blur the history. Worktrees and stacked branches offer different forms of explicitness: one separates working environments, the other separates dependent histories.

Isolate work without hiding it

A worktree is another checked-out working environment associated with the same repository. It lets multiple branches be active at once, so switching from a feature to a preparatory change does not require first packing unfinished edits into a stash or a WIP commit. The distinction is important: a stash is a saved working-tree state that must later be applied or popped, while a worktree gives the branch a place where its current working state remains present and inspectable.

Lazygit's worktree feature is therefore a topology operation, not just a convenience shortcut. The user can create a worktree from a selected branch, move into it, and later remove or detach it. The branch list knows when a branch is checked out in another worktree, which matters because a normal checkout in the current worktree may no longer be the right interpretation. Instead of hiding that constraint, the interface can ask whether to switch to the worktree that already owns the branch. The repository has one set of references, but several working directories can expose different branches at the same time.

This changes the selection question. In a single working copy, “switch branches” often means “what should happen to these uncommitted files?” With worktrees, the question becomes “which working environment should carry the next action?” If the unfinished files belong to the feature branch, leaving them in that branch's worktree keeps their state attached to the correct history. If a second branch needs independent edits, creating or selecting its worktree avoids making the first branch's local state part of the switch decision.

Imagine an urgent maintenance fix arriving while a feature branch has half-finished edits. In one worktree, the user must decide whether to stash, commit, discard, or risk carrying those edits across a checkout. With a second worktree, the maintenance branch can be opened in its own working environment while the feature files remain where they were. The choice has not made the edits safer by itself—the maintenance change can still be wrong—but it has removed an unnecessary state transition from the feature.