A developer fixes a button, but a temporary log and local configuration enter the repository along with the required code. Another common scenario is editing a file after staging it, while the commit retains the earlier version. Both situations are easy to miss when reviewing only the working directory. Checking a commit before pushing helps reveal exactly what the team will receive for review. It is useful for PHP, JavaScript, Python and any other web project whose code is stored in Git.
Three file states that should not be confused
In an ordinary workflow, distinguish the latest commit, the working directory and the index. The working directory contains the files you edit. The index holds the prepared set for the next commit. The latest commit provides the previous comparison point. These states can differ even for one file, so having correct code in your editor does not prove that the upcoming commit contains the right changes.
For example, you stage a stylesheet and then adjust its spacing. The new edit does not automatically become part of the staged set. The git diff command shows working-directory changes relative to the index, while git diff --staged shows staged changes relative to the latest commit. An empty result from the first command does not mean the second will also be empty. They ask different questions about the project’s state.
Keep these checks in a short team checklist available alongside the project documentation.
Understand the file selection before reviewing lines
Start with git status in the intended repository directory. Make sure you are on the expected branch and review staged, unstaged and untracked files. An untracked file will not enter the commit until it is added, but it may be an important part of the fix. For example, a new template may be required for a feature even though the controller changes are already staged. The opposite problem is a staged file that has nothing to do with the task.
Ask a short question about each path: why does this particular fix need it? Separate behavioural changes from accidental formatting, experiments and local settings. Do not delete unfamiliar files just to obtain a clean status: establish their origin first. In a shared working directory, another developer may need unfinished changes. The review should help shape the commit, not destroy the rest of the work.
Pay particular attention to environment configuration, database dumps, logs, archives and user-uploaded documents. Secrets should not enter Git history. An ignore file helps prevent accidental addition of untracked files, but it does not remove an already tracked secret from earlier commits. If a private key or password has already entered the repository, revoke the relevant access and follow a separate history-remediation procedure.
Read the staged diff as a future reviewer
Review git diff --staged --stat to understand the scale, then read the full git diff --staged. The summary shows the number of changed lines but does not explain the meaning of the fix. Check more than added lines: a removed call, condition or error handler can change behaviour more than new code. For binary files, a text diff does not replace opening and checking the material itself.
Imagine an example form change: its button is now disabled while a request is running. A reviewer needs to see not only the disabling but also restoration after an error. Check the relationship between the interface, response handler and user message. If the commit changes only the happy path, the problem may remain after a connection failure. This review is different from simply hunting for typos: it checks whether the solution is complete.
The git diff --staged --check command can detect certain whitespace problems and conflict markers in staged changes. It does not prove program correctness or replace testing. These modes are described in the official Git documentation. Use inspection commands as evidence, not as a ritual after which any set of files is considered ready.
Verify behaviour and leave a clear record
Select checks according to the task. A template change calls for reviewing the relevant page; a total calculation calls for checking expected values and edge cases; an error handler calls for reproducing the failure scenario. Run the tools already used in the project and pay attention to their results. Successful formatting confirms code presentation, not business-logic behaviour. Do not conceal a failed check behind a general claim that everything was tested.
After making fixes, inspect the status and staged diff again: tests sometimes create auxiliary files, while further edits remain outside the index. The commit description should explain the result for the user or system. Instead of a generic update message, state which behaviour changed and why. In the accompanying description, record the checks performed and known limitations so that the next person can assess the work without a verbal handover.
Conclusion: a commit is ready when its contents, behaviour and description agree. One complete set of changes is easier to review than a mixture of unrelated tasks. If your team regularly loses the context of fixes, organise the website technical support process. AriZone can help agree on a practical procedure for reviewing changes and handing over releases for your web project.
Leave a comment