A change is easier to reason about when it has one clear purpose. A focused update lets a reviewer follow the path from the problem to the solution. It also makes it easier to tell what went wrong if the result is not what we expected.
This is not a rule about how many lines belong in a change. Some problems need a broad fix. The useful question is whether each part belongs to the same decision.
Keep the reason close to the code
When a change fixes a bug, updates a dependency, reformats files, and renames a set of functions all at once, it takes more effort to see why each piece is there. Separating unrelated work gives each change a reason someone can understand on its own.
That clarity helps later, too. When someone investigates a regression, the history is more useful if each change describes one thing that happened.
Reduce the cost of being wrong
Software work involves uncertainty. A change may behave differently in production, reveal an overlooked case, or need to be adjusted after people use it. A focused change narrows the area to inspect and makes a correction less risky.
This is one reason I like making progress in steps. Each step provides a chance to learn before the next decision depends on it.
Leave a clear trail
A good change description explains the problem, the approach, and any behavior someone should pay attention to. It does not need to narrate every line. It should give the next reader enough context to understand the choice.
The code is the result, but the reason for the change is part of what future maintainers need to know.