A short command can hide several questions
When learning Git, it is tempting to memorise a sequence of commands and repeat it until something goes wrong. That works while the situation resembles the example. When an unexpected file appears or branches diverge, understanding the state of the work becomes more useful than finding the next command to copy.
I keep coming back to git status. Which branch am I on? Which files changed? What is already prepared for the next commit? These are basic questions, but they describe different things. Asking them first helps me choose a command for a specific intention instead of hoping it matches the problem.
The diff shows the actual change
A filename does not explain what changed inside it. Reading the diff lets me compare added, removed or moved lines with the intended result. A debugging line, configuration edit or formatting change can slip in without belonging to the task. Recognising that extra material is part of preparing the work for someone else to review.
In a hypothetical example, a label correction might sit beside a complete component reorganisation. The question is why those changes need to be reviewed together. If their reasons differ, separating them can make both the review and a later correction easier. The size of a diff then becomes a question of meaning, rather than a line-count target.
Prepare a commit with a clear reason to exist
The index lets me choose what belongs in the next commit. It separates the work still happening in the folder from the version I am preparing to record. That distinction needs attention: the change described by the commit should make sense on its own, especially when several tasks have overlapped in the working directory.
The message follows from that choice. “Fix the archived-project filter” gives more context than “changes” without requiring a long account. An extra explanation can help when a decision would otherwise look surprising. I want the history to preserve an intention, so a reader does not need to reconstruct the entire working session from the lines.
Check what a command will affect before repairing
Reset, restore, checkout and rebase address different needs. When their effects are unclear, I return to the concrete intention: do I want to change a file, reconsider what is staged or alter commit history? Naming that intention helps avoid using a familiar command in a situation where it changes more than I meant to change.
A force push to a shared branch calls for the same care. Replacing remote history requires understanding the differences and the other people involved. It should not become a shortcut for dismissing an inconvenient message. A shared repository also holds the team’s work and reference points, so changes to that history need an understandable reason.
Use history to recover the reasoning
Git also helps me investigate. Comparing versions or reading a commit can reveal when behaviour changed and what the author intended. History provides evidence rather than an automatic explanation: the lines still need to be connected to the application. Coherent commits make that search less confusing, including when I am returning to my own project after a break.
The habits I return to are modest: inspect the state, read the change, group work with a common reason and check the effect of the next command. They cannot remove every mistake. They make the work easier to explain when a mistake does appear, which is often the most useful starting point for fixing it.