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.