Git Basics: Repository, Staging, Diff, and Commit

1. Introduction

Git records project history and makes it possible to understand which analytical code changed and why. A commit is most useful when it contains one coherent change and excludes unrelated or sensitive files.

2. Understand the concept

The working tree contains edits; staging selects the next snapshot; a commit stores that snapshot. git diff shows unstaged edits, while git diff --cached shows staged edits. A commit is local until it is pushed to a remote repository.

3. Syntax and interpretation

git status
git diff
git add analysis.py
git diff --cached
git commit -m "Add monthly revenue summary"

Review the staged diff before committing; the commit message should describe the change rather than say only “update.”

4. Apply it to an analysis

Track analytical code changes and make focused commits that teammates can review. Start with a small, known example and state what each row or value represents. After the transformation, check row counts, types, keys, and units against the original data. If an assumption fails, stop and investigate instead of presenting the output as a valid result.

5. Common mistakes

• Committing every file with git add . without inspecting untracked data exports.
• Assuming a secret is safe after deleting it in a later commit.

6. Practice task

Before committing a notebook project, which command helps review the exact staged changes?

7. One possible solution

Run git diff --cached, along with git status, to inspect staged content and file paths.

8. Summary and next step

Track analytical code changes and make focused commits that teammates can review. Use the next lesson in this module to extend the idea with another technique and a more realistic analysis case.