When Git Stops: Conflicts, Modes, and Recovery
A conflict view in lazygit is a symptom, not a diagnosis. This chapter examines how lazygit identifies the Git operation that is active, separates unresolved files from a merely interrupted workflow, and guides the choice between resolving and continuing, aborting, or recovering through the reflog. The practical result is a disciplined response to a stopped repository: read the state first, change only what the state permits, and never mistake the disappearance of a marker for proof that the result is correct.
An operation can stop because a merge, rebase, cherry-pick, or revert encountered incompatible changes. It can also be in progress because Git is waiting for the user to edit content or provide input. The screen may show a file with conflict markers, an operation banner, or a prompt to continue. Those signs are related, but they answer different questions. One describes the file, one describes the repository operation, and one describes what lazygit believes the next valid transition might be.
Diagnose the state before choosing a remedy
Lazygit detects operation state from metadata that Git leaves in the repository. Rebase directories indicate that a rebase is active; merge, cherry-pick, and revert markers identify their corresponding operations. File status provides a second source of evidence, including conflict categories, staged and unstaged positions, renames, and whether inline conflict markers remain. The application refreshes these facts rather than inferring them from the last key the user pressed. That matters when a conflict was created in another terminal or when an editor changed a file outside lazygit.
Several operation flags can be true at the same time. For example, a cherry-pick can be attempted while a rebase is already stopped, leaving both kinds of metadata present. If the UI treated the state as one simple label, it could offer a continuation that Git would reject or an abort that would target the wrong operation. Lazygit therefore derives an effective state: the operation that currently has priority for what the user can continue or abort. In the documented model, a cherry-pick takes precedence over a merge, and a merge takes precedence over a rebase; the exact precedence is less important than the principle that coexistence is represented rather than discarded.
The effective state is a control decision, not a claim that the other metadata is irrelevant. A rebase may still exist underneath a conflicted cherry-pick, but the cherry-pick must be resolved or aborted first. Only then can the underlying rebase become the operation that matters. The user should read the banner as “this is the state Git will accept the next continuation for,” not as “all other history has disappeared.”
File status adds another diagnostic boundary. A file can have conflict metadata even after a user has edited away the visible markers, and a file can contain marker-like text that is not the conflict syntax Git is looking for. Lazygit can inspect the configured conflict-marker size and, when appropriate, check whether inline markers remain. If markers are gone, the application may auto-stage a resolved file according to its configuration and can offer to continue an operation that lazygit started. Neither behavior establishes that the chosen side or combined content is semantically right.