Managing branches, pull requests, and merge conflicts

Azure Databricks integrates with Git providers (GitHub, Azure DevOps, GitLab, Bitbucket) through Databricks Repos, allowing engineers to manage branching, pull requests, and merge conflicts directly within the workspace or via the underlying Git provider's UI. This enables standard CI/CD workflows for notebooks and code artifacts while keeping production pipelines version-controlled and reviewable before deployment.

1 · Learn the must-know

• 1Databricks Repos supports core Git operations (clone, checkout, pull, push, commit) natively in the workspace UI, letting users create and switch branches without leaving Databricks.
• 2Pull requests themselves must be created, reviewed, and merged in the Git provider's interface (e.g., GitHub, Azure DevOps) since Databricks Repos does not host a native PR review system.
• 3Merge conflicts detected during a pull in Databricks Repos must typically be resolved in the Git provider or via command-line Git, then re-synced into the workspace, as Databricks Repos has limited in-UI conflict-resolution tooling for complex conflicts.
• 4A common CI/CD pattern is to develop on feature branches in Databricks Repos, open a PR for review in the Git provider, and use the main/production branch (often synced to a separate Repos folder) to run scheduled jobs, ensuring production code changes only after merge.
• 5Databricks Repos enforces workspace-level Git integration settings (configured by admins) that control which Git providers and repositories can be linked, so users must have the correct personal access token or credentials configured for their Git provider.
• 6Sparse checkout and repo size limits mean very large repositories may need selective folder checkout when working with Repos, which can affect how branching and file visibility work for pipeline code.

2 · Check your understanding