Why this matters
As a Data Visualization Engineer, you constantly evolve dashboards, charts, and storytelling assets. Git helps you:
- Track changes to code and configs (e.g., chart specs, color themes, SQL queries).
- Experiment safely on branches (try a new layout without breaking main).
- Collaborate with analysts and engineers and resolve conflicts predictably.
- Reproduce results by tagging versions that match published dashboards.
Typical real tasks:
- Version a D3/Plotly chart spec and roll back a styling regression.
- Review a teammate’s branch that updates KPI definitions in a SQL file.
- Ignore large raw datasets while keeping small sample data for local runs.
Concept explained simply
Git is a time machine for your project. You take snapshots (commits) of your work. Branches are parallel timelines where you try ideas without touching the stable one. When ready, you merge your branch into the main branch.
Mental model
Think of your project as a storyboard:
- Staging area: the table where you place frames you want to photograph next.
- Commit: the photograph of those frames with a short caption (message).
- Branch: an alternate storyline (e.g., try a new color palette) that you can later weave into the main story.
Baseline structure for visualization projects
my-dashboard/
README.md
src/ # chart code, SQL, scripts
notebooks/ # exploratory analyses
data-samples/ # small, shareable CSV/JSON (<10MB total recommended)
exports/ # images/PNGs for docs (small)
config/ # themes, chart specs, env templates
docs/ # project notes, decisions
.gitignore
Recommended .gitignore (tailor as needed):
# data and secrets
.env
.env.*
*.key
*.pem
data/
*.parquet
*.zip
*.sqlite
# notebook/IDE noise
.ipynb_checkpoints/
.DS_Store
.vscode/
# build artifacts
node_modules/
dist/
*.log
# large binary dashboard files (store elsewhere if huge)
*.pbix
*.twbx
*.twb
Keep code, configs, and small sample data in Git. Keep large or sensitive data out.
Worked examples
Example 1: Initialize a repo and make an initial commit
- Create and enter the folder:
mkdir my-dashboard && cd my-dashboard - Initialize Git:
git init - Add basics:
echo "# Sales Dashboard" > README.md echo "data/\n.env\nnode_modules/\n.ipynb_checkpoints/" > .gitignore mkdir -p src config data-samples notebooks exports docs - Stage and commit:
git add . git commit -m "chore: initial project setup with structure and .gitignore" - Verify history:
git log --oneline
Example 2: Create a feature branch for a new chart and merge it
- Create and switch to a branch:
git switch -c feat/revenue-trend - Add a chart spec:
echo '{"chart":"line","metric":"revenue","time":"day"}' > config/revenue_chart.json - Commit with context:
git add config/revenue_chart.json git commit -m "feat(chart): add daily revenue line chart spec" - Switch back and merge:
git switch main git merge feat/revenue-trend --no-ff -m "merge: add revenue chart spec" - Check graph:
git log --oneline --graph --decorate
Example 3: Undo changes safely (restore, reset, revert)
- Unstage a file you added by mistake:
git restore --staged config/revenue_chart.json - Discard local edits to a file (not staged):
git restore src/app.js - Revert a bad commit (creates a new commit that undoes it):
git log --oneline # copy the hash of the bad commit git revert <hash> - Back out the last commit but keep changes staged (e.g., to amend message):
git reset --soft HEAD~1
Tip: Prefer revert for shared history; avoid rewriting commits others may have pulled.
Hands-on exercises
All learners can take the exercises and test. Only logged-in users have progress saved.
Exercise 1: Set up a clean repo for a visualization project
Mirror of Exercise ex1 below. Acceptance criteria:
- Repo initialized with structure folders.
- .gitignore includes data, env, and build artifacts.
- One initial commit present.
See instructions
Open Exercise 1 in the Exercises section below for step-by-step instructions, hints, and a full solution.
Exercise 2: Branch, change a chart spec, resolve a conflict, and merge
Mirror of Exercise ex2 below. Acceptance criteria:
- Feature branch created and merged into main.
- Conflict resolved with the intended metric kept.
- Clear commit messages for feature and merge.
See instructions
Open Exercise 2 in the Exercises section below for step-by-step instructions, hints, and a full solution.
Common mistakes and self-check
Common mistakes
- Committing large raw datasets or secrets (.env). Fix with .gitignore and secret management.
- Only working on main, causing unstable demos. Create branches per feature.
- Vague commit messages ("fix stuff"). Use clear intent: type(scope): summary.
- Mixing unrelated changes in one commit. Keep commits focused.
- Rewriting shared history (force-push) without coordination. Prefer merge or revert.
- Not checking diffs before commit. Always review git diff or staged diff.
Self-check
- Your repo stays under reasonable size; large files are ignored or stored elsewhere.
- You can describe what each recent commit did in one sentence.
- main branch always runs; experiments live on feature branches.
- You can recover yesterday’s working chart spec in under a minute.
Practical projects
- Metric Storyboard: Build a small story with 3 charts (retention, revenue, conversion). Branch per chart, then merge.
- Theme Explorer: Create a palette switcher. Use branches per color theme and compare diffs of config files.
- Definition of Done: Update KPI SQL definitions; tag a release when dashboards are consistent with code.
Learning path
- Today: Init, add, commit, log, status, branch, merge, restore.
- Next: Remotes, pull, push, code reviews.
- Then: Branching strategy (feature branches, release tags), tagging versions.
- Later: Handling large files (consider LFS), basic CI to validate charts/linters.
Who this is for
Analysts and Data Visualization Engineers who need reliable versioning of charts, dashboard configs, and supporting code while collaborating with a team.
Prerequisites
- Git installed and a terminal or command prompt.
- Basic understanding of your visualization stack (JS/Python/R, BI configs).
- Text editor to view and edit files.
Mini challenge
Timebox 20 minutes:
- Create a branch feat/color-palette and change primary color in a theme file.
- Commit, then realize the legend font size regressed.
- Use git restore or git checkout to bring back the last good legend config only.
- Merge the branch into main with a clear message.
Hint
Use git log -p to locate the last good change; copy just the needed lines or restore the specific file path from a known commit.
Next steps
- Adopt a simple commit message convention (e.g., feat/fix/chore).
- Create feature branches for each chart or KPI change.
- Tag a version when a dashboard is published to stakeholders.
Quick Test
Take the quick test now. Everyone can take it; only logged-in users will have results saved.