Git Fundamentals For BI Assets

Who this is for

• BI Analysts and Analytics Engineers who work with SQL, dashboards (Power BI/Tableau), notebooks, and analytics documentation.
• Anyone new to Git who wants a safe, repeatable way to track BI work and collaborate.

Prerequisites

• Basic command line familiarity (cd, ls, mkdir).
• Git installed locally and your username/email configured.
• Comfort editing text files (SQL, Markdown, simple configs).

Why this matters

Real BI work changes constantly: metric definitions get refined, dashboards evolve, SQL models are tuned, and documentation improves. Git gives you:

• Traceability: who changed a metric and when.
• Rollback: return to a known-good version if a change breaks a report.
• Collaboration: experiment safely on branches without breaking production.
• Governance: a clear audit trail for compliance reviews.

Concept explained simply

Git stores snapshots of your project over time. You group changes into commits with messages, then organize work on branches. When a branch is ready, you merge it back.

Mental model

• Repository: your project folder plus a hidden .git history.
• Staging area: a waiting room for changes before committing.
• Commit: a labeled snapshot of staged changes.
• Branch: a named pointer to a line of work (main, feature/add-metric).
• Remote: a shared copy others can pull/push to (optional for this lesson).

Key commands you will use

• git init — start version control in a folder.
• git status — see what changed.
• git add — stage changes to include in the next commit.
• git commit -m "message" — save a snapshot with a clear message.
• git branch / git switch -c — create/switch branches.
• git merge — combine another branch into the current one.
• git log --oneline --graph — history at a glance.
• git restore / git checkout -- — discard local changes to a file.
• git revert — safely undo a shared commit by adding a new commit.

# Data dumps and temp artifacts
*.csv
*.xlsx
*.parquet
*.log

# Credentials and local configs
.env
*.key
*.pem

# BI tool caches/outputs
.DS_Store
~$*.xlsx

# Power BI: track templates or source control exports; avoid heavy binaries
*.pbix
*.pbip
# keep .pbit if you use templates

Worked examples

Example 1 — Set up a BI repo with safe ignores

1. Create a project:

   mkdir bi-kpis && cd bi-kpis
   git init
   

2. Add files:

   echo "-- Revenue by day\nSELECT date, SUM(amount) AS revenue FROM payments GROUP BY date;" > models/revenue_daily.sql
   mkdir docs
   echo "# KPI: Revenue\nDefinition: Sum of payments.amount by day." > docs/metrics.md
   

3. Add .gitignore:

   echo "*.csv\n*.xlsx\n.env\n*.pbix\n" > .gitignore
   

4. Commit:

   git add .
   git commit -m "Init repo: revenue_daily.sql, metrics doc, .gitignore"
   

5. Check history:

   git log --oneline
   

Example 2 — Branch, change a metric, and merge

1. Create a branch:

   git switch -c feat/net-revenue
   

2. Edit SQL and docs:

   echo "-- Net revenue by day\nSELECT date, SUM(amount - fee) AS net_revenue FROM payments GROUP BY date;" > models/revenue_daily.sql
   echo "# KPI: Net Revenue\nDefinition: Sum(amount - fee)." > docs/metrics.md
   

3. Commit:

   git add models/revenue_daily.sql docs/metrics.md
   git commit -m "Add net revenue definition and SQL"
   

4. Merge to main:

   git switch main
   git merge feat/net-revenue
   

5. Inspect:

   git log --oneline --graph --decorate
   

Example 3 — Safe rollback using revert

1. Create a change:

   echo "Note: excludes refunds" >> docs/metrics.md
   git add docs/metrics.md
   git commit -m "Docs: note excludes refunds"
   

2. Decide to undo it:

   git log --oneline
   # copy the commit hash of the last docs change
   git revert <hash>
   

3. Review:

   git log --oneline
   

Exercises

Do these locally. Aim for small, clear commits and safe ignores.

Exercise 1 — Initialize and structure a BI repo

Goal: create a repository that tracks code/docs but ignores data dumps and secrets.

1. Create a folder named bi-metrics and initialize Git.
2. Add files: models/orders_daily.sql, docs/metrics.md, .gitignore (ignore *.csv, *.xlsx, .env, *.pbix).
3. Stage and commit with message: "Init: orders_daily model, metrics doc, .gitignore"
4. Create a branch feat/add-aov-metric; modify docs/metrics.md to add Average Order Value (AOV) definition and update models/orders_daily.sql to include total_amount.
5. Commit changes with a clear message; merge to main and view a compact log.

Exercise 2 — Practice a merge conflict and resolve it

Goal: experience a simple conflict in a SQL file and resolve it correctly.

1. On main, create models/customers_daily.sql with a SELECT and commit.
2. Create branch feat/rename-column and change a column alias (e.g., customer_cnt to customers).
3. Switch back to main, create branch hotfix/keep-original and change the same line but with a different alias (e.g., customer_total).
4. Merge feat/rename-column into main, then merge hotfix/keep-original into main to trigger a conflict.
5. Open the conflicted file, choose the final alias you want, remove conflict markers, stage, and complete the merge.

• Checklist for both exercises:
  • ☐ .gitignore stops large data files and secrets from being tracked.
  • ☐ Commits are small and messages are specific.
  • ☐ Branch names describe the change (feat/, fix/, docs/).
  • ☐ git log shows a clear history without noise.

Common mistakes and self-check

• Mistake: Committing raw data exports and secrets. Self-check: git ls-files | grep -E "(\.csv|\.xlsx|\.env)" should return nothing important.
• Mistake: Vague messages like "update". Self-check: Does each message complete the sentence "This commit…"?
• Mistake: Working on main for risky edits. Self-check: Did you create a feature branch for each change?
• Mistake: Large binary dashboards bloating the repo. Self-check: Are heavy .pbix files ignored or handled as templates?
• Mistake: Giant commits mixing unrelated changes. Self-check: Could you revert a single change easily? If not, your commits are too broad.

Practical projects

• Small BI project template:
  • Create a repo structure: models/, notebooks/, dashboards/, docs/, tests/.
  • Add a README describing KPIs and data sources.
  • Include a robust .gitignore and a .env.example.
• Metric evolution history:
  • Track a KPI definition over five commits (v1 to v5), tagging v1.0, v1.1, etc.
  • Practice reverting one change that introduced a logic error.
• Branch-based dashboard iteration:
  • Simulate three parallel feature branches editing different SQL models.
  • Merge in sequence and resolve any conflicts; document what you learned.

Learning path

• Before: Command line basics; source control mindset.
• Now: Git fundamentals for BI assets (this lesson).
• Next: Collaboration patterns (code reviews, pull requests), branching strategies, tagging releases to deployment.

Mini challenge

Create a new repo for a hypothetical KPI: Active Users.

• Add models/active_users.sql and docs/active_users.md.
• Commit, then add an experiment on a branch that changes the definition (e.g., last 28 days vs last 30 days).
• Decide which you prefer; merge one and revert the other to document the decision.

Next steps

• Run the exercises if you haven’t.
• Take the Quick Test to solidify concepts. The quick test is available to everyone; if you’re logged in, your progress is saved.
• Apply this to a real BI task at work or in a portfolio project.