Review the change with Git

Version control gives analytics work a reviewable history. This lesson applies that to your pipeline change. For the full Git and GitHub workflow - setup, branches, pull requests, and publishing - follow GitHub for data practitioners. Here you review this project before sharing it.

A good 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 on release.

Inspect your working tree

Run these from the repository root:

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

git diff --check catches whitespace errors. The diff should contain your pipeline files, example CSVs, and documentation. It should not contain .bruin.yml, commerce.duckdb, passwords, keys, editor state, or unrelated files. If local state appears, add it to .gitignore before you stage:

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

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, improve the file header or documentation before committing.

Ask your coding agent

Stage and commit

Stage explicit paths, not git add ., so a credential file or local database cannot slip in by accident:

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

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

To turn this project into a public portfolio piece, follow Build a data portfolio on GitHub.

Checkpoint

Your branch should hold one focused commit with a diff free of local database files and credentials, plus a pull request summary another analyst can review without reconstructing the business request.