The Lazygit Operating Model

Lazygit answers a deceptively difficult question: how can Git become easier to operate without becoming less visible? The answer is not a feature checklist or a promise that every risky action can be undone. It is an operating model in which the user observes repository state, selects the smallest intention that matches the change, lets Git or an explicitly chosen external tool carry it out, and verifies the resulting state before moving on. This conclusion brings those distinctions together so a reader can approach an unfamiliar task through judgment rather than memorized shortcuts.

The model matters because Git actions differ less by their names than by the state they cross. A selection can change only the view, or it can change the index, working tree, commit graph, branch references, or a remote. A command can finish immediately, or it can leave a rebase or merge waiting for resolution. A customization can improve findability, or it can place a shell command between the user's selection and the refreshed repository. Lazygit makes these transitions easier to reach and inspect; it does not erase their different consequences.

Start with state, not with a shortcut

The most reliable first move is to read the repository projection that answers the current question. If the question is “what have I changed?”, the Files view and its staged/unstaged distinctions are relevant. If it is “where did this behavior enter history?”, the commit graph and a commit's patch are relevant. If it is “which line of work should I continue?”, branch, upstream, and worktree relationships matter. If Git has stopped, the operation state and conflicted files matter before any ordinary branch or commit action.

This is not a demand to inspect every panel. It is a demand to identify the state boundary. A file can be selected without being staged. A commit can be selected without being rewritten. A branch can be selected without being checked out or pushed. A worktree can hold unfinished files that should not be carried into the current directory. A status banner can describe a persisted operation that changes what Git will accept next. The narrowest useful observation is the one that tells the user which object owns the next decision.

From there, name the intention in terms of its destination. If the goal is to prepare part of a file for a commit, the destination is the index, so a line, range, or hunk is the likely unit. If the goal is to correct an older commit while keeping the change visible to a reviewer, the destination is a fixup or amend relationship in history. If the goal is to work on two branches without hiding unfinished files, the destination is a worktree. If the goal is to integrate or communicate a branch, the destination may be an upstream, pull request, or remote.

The destination test prevents a common mistake: choosing a command because its label sounds close to the task. “Commit” can mean a new independent decision or an immediate amendment. “Rebase” can mean moving a branch, changing TODO actions, or extracting a selected patch. “Undo” can mean a reflog-backed reference movement, not restoration of arbitrary files. The interface can make several options available, but the user must choose among them by the state they intend to change.

Choose the smallest operation that preserves meaning

For everyday edits, precision is usually a better tie-breaker than speed. A line is the right unit when one addition or deletion stands alone. A range expresses one contiguous logical change. A hunk is appropriate when the surrounding edits belong together. The staged and unstaged views then provide a concrete check: the selected content should cross into the index, while intentionally separate work remains visible outside it. A larger selection may require fewer keypresses, but it also makes a stronger claim about what belongs in the same next snapshot.

For review corrections, history has an additional meaning. A new commit is appropriate when the correction is independently useful or the existing history should not be rewritten. A fixup commit is appropriate when the correction belongs to an earlier commit but should remain visible during review. An amend can directly change a local commit when the work is private and the target is unambiguous. A squash is appropriate when intermediate commits no longer carry useful information. A custom patch is appropriate when the content that must move is smaller than an entire commit.

This is why a clean graph is not always the immediate goal. Suppose a reviewer asks for a validation change in a commit that introduced a configuration option. Creating a fixup makes the response explicit: the reviewer can inspect the correction, and the branch can later autosquash it.