Loadingone moment…
An analyst's SQL becomes an engineer's model the day it moves into a repository and starts going through review. These are the commands that day needs — not a git course, just the working set.
Nothing about git is specific to data. What is specific is why a team insists on it the moment SQL stops being ad-hoc.
A query in a BI tool has no history, no author, and no way to be reviewed before it changes a number somebody reports upstairs. A model in a repository has all three, and that is the entire argument. Every dbt project, every Airflow DAG and every pipeline you will touch lives in one.
You need far less of git than its reputation suggests. The commands below cover the normal week; everything else can be looked up on the day you first need it.
Run these the first time you touch a repository, and then rarely again.
git clone <url>git config user.name "…"git config user.email "…"git statusBranch, change, commit, push, open a pull request. That sequence is ninety per cent of git as it is actually used.
git checkout main && git pullgit checkout -b add-orders-staging-modelgit status && git diffgit add models/staging/stg_orders.sqlgit commit -m "Add stg_orders with order_id uniqueness test"git push -u origin add-orders-staging-modelgh pr create --fillA commit on main usually skips review and can trigger a production run. Branch first, always — the branch costs you one command and is the whole point of the workflow.
Read your own diff before anyone else has to. Most review comments on a data pull request are things the author would have caught here.
git diffgit diff --stagedgit log --oneline -10git restore <file>git restore --staged <file>The one genuinely confusing situation, and it is common in a dbt project because everybody touches the marts.
A conflict means git could not decide which of two edits to the same lines should win, so it is asking you. It marks the file with <<<<<<< and >>>>>>> around both versions. You open the file, delete the markers, leave the SQL you actually want, and commit.
git pull origin maingit statusgit add <file> && git commitdbt build --select state:modified+Merging two valid queries can produce a third that compiles and is wrong — a filter from one side and a join from the other. Always run the model after resolving, never just push because the markers are gone.
One change per branch. A branch that adds a staging model and also renames a mart column cannot be reviewed, cannot be reverted cleanly, and will sit unmerged for a week.
A commit message says why, not what. The diff already shows what changed; "Add stg_orders with order_id uniqueness test" is useful in six months, "update sql" is not.
Pull main before you branch, and again before you open the pull request. Most conflicts are simply a branch that has been away from main for too long.
profiles.yml, .env and anything with a warehouse password stay out — add them to .gitignore before your first commit. A pushed secret is public even after you delete it, because the history keeps it.