GitHub Step 3 of 5

GitHub for data practitioners

Keep code and secrets separate

Git should hold the project files that explain how data moves and changes: SQL, Python, YAML, tests, checks, documentation, and example configuration. It should not hold production credentials, access tokens, private keys, or warehouse connection strings.

Check the project's .gitignore before the first commit. A basic data project often ignores files like these:

# Credentials and local configuration
.env
.bruin.yml
profiles.yml

# Local build output and databases
target/
*.duckdb

# Notebook checkpoints
.ipynb_checkpoints/

Git is for the code that describes your data, not the data itself. Keep raw datasets, exports, and large files out of the repository and load them from storage, a warehouse, or a download step instead.

For Bruin, keep the project and pipeline definitions in Git, but use .bruin.yml or your approved secret manager for connections. For dbt, commit dbt_project.yml, models, schema tests, and macros, but keep profiles.yml outside the repository. Run git status before staging anything. If a file looks like a credential, do not add it.

Commit an example configuration so collaborators know which values they need. A .env.template or .bruin.yml.example with empty or placeholder values documents the setup while the real file stays ignored. If you ever commit a secret by mistake, treat it as exposed and rotate or revoke it. Removing the file in a later commit does not erase it from history.

If you work in Jupyter notebooks, clear the cell outputs before you commit. Outputs bloat the diff, make review hard, and can quietly push sample rows or credentials into Git. Clear them from the notebook menu, or add a tool such as nbstripout so it happens on every commit.

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.