27. How to Use Git with Jupyter Notebooks for Data Projects
27.1 Why Git for Notebook Data Projects
Why. Ruhi emails pune_eda_final2.ipynb. Amir edits a copy called pune_eda_final2_amir.ipynb. On Monday nobody knows which file built the Diwali chart. Git stores history — who changed what, and you can go back.
What.
- Repository (repo) — a project folder tracked by Git.
- Commit — a snapshot with a message.
- Remote (optional) — GitHub/GitLab copy for backup and teammates.
How.
Mindset for analysts
- One project folder = one repo.
- Code + notebook logic in Git; large raw data usually out.
- Commit when a small unit works (“city filter fixed”), not once a month.
- Pull/push only when you use a remote — local Git still helps alone.
- Treat secrets like production passwords (Chapter 24 / 26 habits).
Worked example A — Bad naming (fictional).
eda.ipynb → eda_v2.ipynb → eda_v2_FINAL.ipynb → eda_v2_FINAL_use_this.ipynb. Git replaces this mess with commits.
Worked example B — Good story.
commit 1: add raw sample + empty notebook
commit 2: clean city names for Maharashtra
commit 3: add Pune vs Nashik GMV chart
Worked example C — What Git is not in this chapter.
Not a full DevOps course. Not branching strategy for 50 engineers. Just enough so your Blinkit lab is reproducible.
Ravindra Bagale's Tip
final_v3 = danger. Commit message = time machine chi key.