Using Git the way a Databricks project should

Azure Databricks integrates with Git through Databricks Repos, letting you clone, branch, commit, and push notebooks and files to a remote Git provider directly from the workspace. This enables standard software engineering practices—code review, branching strategies, and CI/CD—to be applied to data engineering pipelines built in Databricks.

1 · Learn the must-know

• 1Databricks Repos supports major Git providers including GitHub, GitLab, Bitbucket, and Azure DevOps, requiring a personal access token or credential configured in User Settings before cloning.
• 2Notebooks stored in Repos are saved in source format (e.g., .py, .sql, .scala files with special comment headers) rather than the .dbc archive format, making diffs clean and human-readable in pull requests.
• 3Only files can be tracked via the Databricks UI Git panel (pull, push, commit, branch switch); merge conflict resolution beyond simple cases typically requires resolving in an external Git client or the provider's web UI.
• 4A common CI/CD pattern is to develop in a feature branch within a Repo, open a pull request for review, merge to main, and then use Databricks CLI/REST API or Repos API to programmatically pull the latest main branch into a production Repo path used by scheduled jobs.
• 5Sensitive credentials and secrets should never be hardcoded in notebooks committed to Git; use Databricks Secrets (backed by Azure Key Vault or Databricks-managed scopes) instead.
• 6Workspace admins can restrict which Git providers or repository URLs are allowed, and per-user Git credentials mean each collaborator authenticates individually rather than sharing a single service credential.

2 · Check your understanding