Use Git to review changes to an analysis script
In this article (6 sections)
Review an analysis change at two levels: what the code changed and what the reported result changed. A one-character diff can alter the reporting population, while a large refactor can leave every business result unchanged.
Git makes the textual change visible. A controlled fixture and expected results explain its analytical consequence.
Begin with the scope of the change
Before reviewing, inspect git status --short --branch to identify the current branch and modified files. Separate the intended analysis change from unrelated notebooks, generated outputs or local configuration.
Use git diff -- path/to/script.py for unstaged changes and git diff --cached -- path/to/script.py for staged changes. The git diff reference documents those comparisons. They answer different questions; checking only one can miss work in the other area.
The commands in this article are review examples. They do not require committing or publishing a project.
See a small diff with a large consequence
This executable example creates two temporary files and asks Git to compare them without a repository. It changes a half-open date boundary into an inclusive upper boundary.
from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess
with TemporaryDirectory() as directory:
before = Path(directory) / "before.py"
after = Path(directory) / "after.py"
before.write_text("selected = start <= order_date < end\n", encoding="utf-8")
after.write_text("selected = start <= order_date <= end\n", encoding="utf-8")
result = subprocess.run(["git", "diff", "--no-index", "--", str(before), str(after)],
capture_output=True, text=True, check=False)
assert result.returncode == 1
assert "-selected = start <= order_date < end" in result.stdout
assert "+selected = start <= order_date <= end" in result.stdout
print("Git exposes the changed upper-bound comparison")For this comparison, exit code 1 indicates differences, not a failed analytical test. The example requires Git to be installed. It writes only inside a temporary directory and does not alter the current repository.
Connect the diff to a metric
The Python reporting lab reports January using January 1 inclusive through February 1 exclusive. Its accepted February 1 paid order is INR 10.00.
Changing the upper bound to inclusive would incorrectly add that order to January, moving the total from INR 47.50 to INR 57.50. A reviewer who sees only a green syntax check could miss the business error.
The boundary tests therefore matter as much as the diff. Ask which fixture record demonstrates the intended interpretation and whether the changed implementation still passes that case.
Review more than formatting
Look for changes to joins, filter order, default values, null handling, duplicate policy, rounding and output grain. A renamed variable may be harmless; changing a default missing amount to zero is a semantic decision.
Inspect generated output only when it helps establish the change. A large reordered CSV can obscure the meaningful differences. Compare stable keys and report added, removed and changed records alongside aggregate controls.
Do not commit raw private datasets or credentials merely to make a reproduction convenient. A synthetic fixture with a documented schema can demonstrate the defect without copying the production source.
Make the review reproducible
A useful handoff identifies the problem, the intended before/after behavior and the exact verification command. Include known limitations, such as Excel or DAX examples that still require their application runtime.
For the Python lab, python verify.py runs the reference tests. A reviewer can additionally run the CLI for January and inspect the summary and rejected records. The code revision, input hash and reporting parameters together provide stronger provenance than any one field alone.
Exercise: create a disposable copy with the inclusive-upper-bound change. Write a review comment explaining the extra February order, then restore the correct comparison and demonstrate the passing boundary test.
NeuraPath's Data Analytics with Generative AI course connects analytical scripting with review habits. A useful code review protects the meaning of the reported number, not just the appearance of the source file.
Continue learning
This article is part of the Python foundations for analysts sequence. Use the neighbouring tasks when you need the prerequisite or the next application.
- Review the prerequisite or neighbouring task in Python generators for processing a large file incrementally.
- Continue with Review AI-generated Python before using its output.
Pankit Kumar has 10 years in Data Science & AI, building and shipping production systems in regulated pharma and clinical environments. He is a freelance trainer at Boston Institute of Analytics, AnalytixLabs and Scaler, and has taught this material to thousands of working professionals.
This article is part of our Data Analytics with Generative AI programme — 3–4 months. The full analyst stack — Excel, SQL, Power BI and Python pipelines — then a generative-AI layer you can prove is right.
Explore Data Analytics with Generative AI