Version Control Git

What is Version Control (Git) for Analytics Engineers?

Version control with Git is how analytics engineers safely collaborate on SQL models, dbt projects, BI transformations, and documentation. It gives you: traceability of every change, code reviews before deployments, safe releases to dev/stage/prod, and quick rollbacks when something breaks.

Who this is for

• Analytics Engineers building dbt/SQL transformations and BI-ready datasets.
• Data Analysts contributing SQL or documentation via pull requests.
• Data/ML folks who need reliable, reviewable change management.

Prerequisites

• Basic command line comfort (cd, ls, running commands).
• Working knowledge of SQL and a dbt-style project structure.
• Familiarity with environments (dev, stage, prod) conceptually.

Why Git matters in analytics engineering

• Prevents breaking production tables by isolating changes on branches.
• Enables peer review of SQL logic, tests, and data contracts.
• Supports CI checks to run dbt tests/builds before merge.
• Tags let you release versions and roll back fast when needed.

Learning path

Worked examples

git init
# Example .gitignore for data/dbt projects
# Python/venv
.venv/
__pycache__/
*.pyc

# dbt local artifacts
logs/
target/
.dbt/

# OS/editor
.DS_Store
.idea/
.vscode/

# Data exports or local CSVs
exports/
*.csv
*.parquet

# Credentials - never commit!
.env
secrets*.json
  

git add .
git commit -m "chore: bootstrap repo with dbt structure and .gitignore"
  

# Create and switch to a feature branch
git checkout -b feat/customer-ltv

# Work on your model and tests
# models/marts/customer_ltv.sql
# tests/schema.yml (add tests)

git add models/marts/customer_ltv.sql tests/schema.yml
git commit -m "feat: add customer_ltv model with schema tests"

git add models/marts/customer_ltv.sql
git commit -m "refactor: tune window logic for retention calculation"

# Keep commits small and reviewable
  

# In models/marts/orders.sql
<<<<<<< HEAD
select order_id, customer_id, total_amount
=======
select order_id, customer_id, total_amount, discount_amount
>>>>>>> feat/add-discounts
  

select
  order_id,
  customer_id,
  total_amount,
  coalesce(discount_amount, 0) as discount_amount
from {{ ref('stg_orders') }}
  

git add models/marts/orders.sql
git commit -m "fix: resolve merge conflict preserving discount_amount with default"
  

# After merging to main and validating in stage
git checkout main
git pull

git tag -a v1.4.0 -m "Release: Q2 revenue models, adds customer_ltv"
git push --tags

# If production issue occurs, revert safely
# Option A: revert a specific commit
git revert <bad_commit_sha>
# Option B: rollback to a prior tag (fast fix, then follow with a hotfix branch)
# Create a hotfix from the last good tag
git checkout -b hotfix/revert-to-v1.3.2 v1.3.2
# Apply minimal fix, test, PR, then tag e.g., v1.3.3
  

Environment-based workflows (dev → stage → prod)

• Develop on feature branches, building models in your dev schema or database.
• Merge to main and deploy to stage. Run data tests and sample validations.
• Tag a release and promote to prod. Monitor freshness and key metrics.
• If issues arise, revert the commit or roll back to the last known-good tag.

CI & secrets basics

# Example pipeline steps (conceptual)
- checkout repo
- set up Python environment
- install dbt + adapters
- set env vars for credentials (never commit secrets)
- dbt deps
- dbt build --select state:modified+ --state target
- post results to PR status
  

Drills and exercises

• Create a feature branch, add a new model, and make two small commits instead of one big commit.
• Open a PR with a checklist; include before/after row counts from dev to show impact.
• Simulate a merge conflict by editing the same SQL line on two branches; resolve it cleanly.
• Tag a release and then practice a revert of a single commit.
• Set a main-branch protection rule locally (require reviews) and try to push directly; confirm it is blocked.

Common mistakes and debugging tips

• Pushing directly to main: protect main and require PR reviews.
• Huge commits: split into small, logical commits to ease reviews and rollbacks.
• Forgetting tests/docs: add schema tests and column descriptions alongside model changes.
• Unclear commit messages: use a convention like feat/fix/chore/docs for clarity.
• Committing secrets: add .env and secret patterns to .gitignore; rotate credentials if leaked.
• Merge conflict panic: read both sides carefully, preserve required columns, then re-run local builds/tests.
• No tags: without tags, rolling back is harder. Tag stable releases.

Mini project: Ship a Sales Mart safely

Practical projects

• Analytical Contract Update: Add new columns to a fact table with backwards-compatible SQL, tests, and a tagged release.
• Dimension Refactor: Rename and deprecate columns via a two-step release, proving zero-downtime for downstream dashboards.
• CI Hardening: Introduce a minimal PR pipeline that builds only modified dbt models and posts status checks.

Next steps

• Practice branching/PRs on every change until it becomes automatic.
• Add tags to every production deployment.
• Expand CI checks to include data quality gates before merge.

Subskills

• Branching Strategy For Data Work — organize feature branches and short-lived changes.
• Pull Requests And Code Reviews — ensure correctness, tests, and documentation before merge.
• Commit Hygiene And Messages — write small, clear commits that are easy to review and revert.
• Managing Conflicts In SQL Models — resolve merge conflicts without losing important logic.
• Environment Based Workflows Dev Stage Prod — promote changes safely through environments.
• Tagging Releases And Rollbacks — version your deployments and recover quickly from failures.
• Protecting Main Branch — prevent direct pushes and require reviews/CI.
• Working With CI For Data Projects — run builds/tests on PRs to catch issues early.
• Storing And Rotating Secrets Safely Basics — keep credentials out of the repo and rotate regularly.