Course overview/Ship with confidence3 of 3

Review the change with Git

Back to course

Ship with confidence - Step 11 of 15

Review the change with Git

Inspect the diff and review modeling decisions before sharing the work.

Treat the pipeline as software

Version control gives analytics work a reviewable history. A pull request should explain the business change, show the modeling decisions, and include evidence from a narrow run.

The review is not limited to SQL style. Reviewers need enough context to question what each row means, whether joins duplicate data, how the table updates, what is tested, who owns it, and what could go wrong when it is released.

Inspect your working tree

Run these commands from the repository root:

git status --short
git diff --check
git diff

git diff --check catches whitespace errors. The full diff should contain the pipeline files, example CSV files, and documentation you created. It should not contain .bruin.yml, commerce.duckdb, passwords, keys, editor state, or unrelated files.

Update .gitignore if local state appears in the diff:

.bruin.yml
*.duckdb
*.duckdb.wal
logs/

The setup lesson creates these rules. If you are reviewing an older project, add any missing rule before you stage files.

Review the modeling decisions

Read the diff as if somebody else wrote it. Check:

  • The daily revenue table has one row per customer per calendar day.
  • The customer join remains many orders to one customer.
  • Paid status is the only input to recognized revenue.
  • The composite key is tested as a pair.
  • The date filter includes the same start and end dates that Bruin replaces.
  • Owners and metric limitations are documented.
  • The change contains no passwords or keys.

If the diff cannot answer one of these points, improve the settings in the file header or the project documentation before committing.

Ask your coding agent

AI Prompt

Review the current Git diff for this analytics engineering course project. Do not edit, stage, commit, or push anything.

Check for:

  • files outside the course project
  • passwords, keys, .bruin.yml, or DuckDB files
  • joins that can duplicate rows
  • a mismatch between the row definition and its checks
  • a mismatch between the date filter and table update settings
  • missing owners or metric limitations

Report findings from highest to lowest risk and cite the file path and line. If nothing is wrong, say what you checked and which commands you ran.

Stage and commit the course project

If Git asks for an author identity when you commit, set it for this repository:

git config user.name "Your Name"
git config user.email "[email protected]"

These commands change this repository's Git configuration only. Replace the example values with the name and email you want attached to the commit.

git add .gitignore commerce
git diff --cached --check
git diff --cached
git commit -m "build customer daily revenue pipeline"

Do not use git add . by habit in a data project. Staging explicit paths makes it harder to commit a credential file or local database by accident.

Draft the pull request summary

Use this structure even if the repository is only local:

## Business change

Adds daily recognized revenue by customer and country.

## How the table is built

- One row: customer and order date
- Recognized revenue: paid order amount only
- Customer country: current value from the customer dimension
- Update method: replace the requested order-date range

## Evidence

- Pipeline validation passes
- January 2 rerun does not create duplicate rows
- C001 on January 1 matches 49.00 recognized revenue in the source

## First run and recovery

- Create a new time-interval table once with `--full-refresh`
- Run a narrow date window without `--full-refresh`
- Rebuild an affected date interval if source records change

Publish a portfolio project later

Git works locally. GitHub stores a copy of the repository online. Once the project is finished, you can publish it so other people can read the SQL, documentation, and project history.

Before publishing:

  • Add a README.md that explains the question, the project structure, how to run it, and what you checked.
  • Confirm that .bruin.yml, DuckDB files, passwords, and keys are not tracked.
  • Review git status, the committed files, and the repository visibility.

GitHub's Hello World guide walks through creating a repository, working on a branch, committing changes, opening a pull request, and merging it. Those are the same steps you will use for analytics projects.

Ask your coding agent

AI Prompt

Help me prepare this analytics engineering course project as a GitHub portfolio repository.

First, inspect the current branches, commits, remotes, tracked files, and .gitignore. Explain what each Git command does. Draft a README.md that covers the business question, project structure, tools, run command, checks, and expected result.

Then propose the safest steps to create the GitHub repository and push the current work. Ask me to choose the repository name and whether it should be private or public. Do not create the repository, change its visibility, rewrite history, push, or merge until I approve the exact plan.

Checkpoint

Your branch should contain one focused commit, and its diff should be free of local database files and credentials. You should also have a pull request summary that another analyst can review without reconstructing the business request. Publishing to GitHub is optional, but you should understand the steps and know what must stay private.

Sign up to our newsletter

Practical updates on open-source data pipelines, AI analysts, governance, and what we are shipping at Bruin.

The signup form is hosted by Brevo. Accept cookies to load it.