What you will be able to do
- Describe the admin, user and merge flows that make up Git-folder-based CI/CD on Databricks
- Run the feature-branch collaboration loop from a user-level Git folder through to a merged pull request
- Tell a production Git folder apart from a user-level Git folder by location, owner, contents and permissions
Key concept
Production Git folder — A Git folder that an admin creates outside the user folders. It is checked out on a deployment branch, and only automation updates it. Users develop in their own Git folders. Jobs run from the production folder.
1.Three flows that make up Git folder CI/CD
Databricks Git folders (formerly Repos) put a remote Git repository inside your workspace. From there you can clone, branch, commit, push and pull on notebooks and files. To use them for CI/CD, you set up the folders once and then automate Git operations from there. Databricks describes the automation as resting on two things: initial folder configuration and the Databricks Repos REST API. Before you automate anything, decide which repositories and branches belong to each stage: development, integration, staging and production.
The documentation describes three flows. In the admin flow, a workspace admin creates top-level folders to hold production Git folders. The admin clones a repository and branch into each one and names the folder for its purpose, such as "Production", "Test" or "Staging". In the user flow, each developer creates a Git folder under /Workspace/Users/<email>/, works on their own branch and pushes commits to the remote. In the merge flow, developers open pull requests. When one is merged, automation pulls the change into the production Git folders.
| Flow | Who acts | Where | What happens |
|---|---|---|---|
| Admin flow | Workspace admin | Top-level folders outside user folders | Clones a repo and branch into each folder and names it by purpose (Production, Test, Staging) |
| User flow | Individual user | /Workspace/Users/<email>/ | Works on a user-specific branch and pushes commits to the remote |
| Merge flow | Automation (Repos API) | Production Git folders | Pulls merged changes after a PR lands in the deployment branch |
Checkpoint 1 of 4· Check yourself
In the Git folders CI/CD model, where does a developer create their working Git folder?
In the user flow, developers work in Git folders under their own user directory. The top-level stage folders belong to the admin flow.
“A user creates a Git folder under /Workspace/Users/<email>/ from a remote repository, works on a user-specific branch, and pushes commits to the remote.”Source: docs.databricks.com
Sources1
2.The user flow: feature branches and pull requests
Inside the user flow, a common pattern is a feature or development branch that collects work. You clone the repository into your workspace and create a feature branch from main in the Git folders UI. You can have as many feature branches as you need. Then you edit notebooks and files and commit and push to the remote. Other contributors clone the same repository into their own user folders and do the same on their own branches. When the work is ready, you open a pull request on your Git provider, review it with your team and merge it into the deployment branch. Databricks recommends one branch per developer.
Checkpoint 2 of 4· Put it in order
Put the feature-branch collaboration steps in order.
- 1.Commit and push your changes to the remote repository
- 2.Clone the existing Git repository into your Databricks workspace
- 3.Create a PR on your Git provider, review it, and merge into the deployment branch
- 4.In the Git folders UI, create a feature branch from the main branch
- 5.Edit Databricks notebooks and other files in the repo
The documentation gives the steps in this order: clone, branch, edit, commit and push, then PR and merge. Merging into the deployment branch is what starts the merge flow.
“When ready, create a PR on your Git provider, review with your team, and merge into the deployment branch.”Source: docs.databricks.com
Separate folders and branches matter because of how a Git folder handles switching branches. The working branch belongs to the folder, not to the person looking at it. If several users share one Git folder in the same workspace, one person's branch switch changes the branch for all of them. A switch can also delete workspace assets that don't exist on the new branch. Switching back recreates those assets with new IDs and URLs, and that change can't be undone.
They see the new branch too. When users in the same workspace share a Git folder, a branch change applies to everyone. Notebooks that aren't on that branch can also disappear, and if they come back they have new IDs and URLs. Giving each developer their own Git folder under /Workspace/Users/<email>/ avoids this.
3.Production Git folders versus user-level Git folders
A user-level Git folder is a local checkout where someone develops and pushes. A production Git folder has a different job. An admin creates it outside the user folders and checks it out on a deployment branch, and automated workflows run from it. It should change only when automation updates it after a pull request is merged into the deployment branch. Its permissions are set to protect that. Most users get run-only access, and only admins and Databricks service principals can edit it.
| Property | User-level Git folder | Production Git folder |
|---|---|---|
| Location | /Workspace/Users/<email>/ | Subfolder under Workspace, outside user folders (per project, team or stage) |
| Created by | The developer | A workspace admin |
| Branch | User-specific or feature branch | Deployment branch |
| Updated by | The developer (commit, push, pull) | Only automation, when PRs merge into the deployment branch |
| Who can edit | The developer | Only admins and Databricks service principals; most users get run-only access |
Checkpoint 3 of 4· Check yourself
An engineer has a hotfix ready. They have edit permission on the production Git folder and want to commit there directly to save time. What does the Databricks guidance say?
Only automation should update production Git folders, and only after a merge. Admins and service principals do keep edit access, so 'read-only for everyone' is wrong too.
“They should be updated only by automation when PRs are merged into deployment branches.”Source: docs.databricks.com
Checkpoint 4 of 4· Exam question
A data engineering team merges pull requests into the `main` branch of a GitHub repository linked to a production Git folder at `/Workspace/Production/etl-pipeline`. They want a GitHub Actions workflow that runs immediately after a merge to `main` so that scheduled jobs reading from that folder pick up the new code automatically. Which action should the workflow perform using the Databricks REST API?
Correct answer: A — Call the repos update endpoint with the production Git folder's object ID and set `branch` to `main`, using a token that has edit access to the folder.
- A. This is correct because the Repos REST API's update operation is the mechanism Databricks provides for programmatically pointing a Git folder at a specific branch and pulling its latest commit, which is exactly what an external CI/CD step needs to do after a merge. Because production folders typically restrict most users to run-only access, the automation must authenticate with a service principal or credential that has edit permission on that folder.
- B. This is incorrect because `repairrun` only reruns failed job tasks with the same or overridden parameters; it does not instruct a Git folder to sync with a new commit, so the job would simply rerun against whatever code was already checked out.
- C. This is incorrect because the Workspace API's export/import operations move file content directly and bypass Git entirely, which breaks the Git folder's branch tracking and defeats the purpose of a Git-based CI/CD workflow.
- D. This is incorrect because bundle deployments target the resources and files defined in a bundle's own deployment configuration; they do not reach into an unrelated Git folder and update its checked-out branch as a side effect.
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Developers with edit rights can commit or pull straight into the production Git folder when they're in a hurry.Why is that wrong?
Only automation should update production Git folders, after a PR is merged into the deployment branch. Most users get run-only access.
Covered in Production Git folders versus user-level Git folders
2.A team can share one Git folder, and each person switches to their own branch when they need it.Why is that wrong?
The branch belongs to the folder. When users in the same workspace share a Git folder, a branch switch changes the branch for all of them. Databricks recommends a separate branch for each developer.
Covered in The user flow: feature branches and pull requests
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.databricks.com/aws/en/repos/ci-cdOfficial docs
“Automation for Git folders centers on initial folder configuration and on the Databricks Repos REST API for automating Git operations from Databricks jobs.”
↩︎ Three flows that make up Git folder CI/CD“A Databricks workspace admin creates top-level folders to host production Git folders.”
↩︎ Three flows that make up Git folder CI/CD“Choose the right repos and branches for each stage (development, integration, staging, production).”
↩︎ Three flows that make up Git folder CI/CD“Databricks recommends that each developer work on their own branch.”
↩︎ The user flow: feature branches and pull requests“User-level folders are local checkouts where users develop and push changes.”
↩︎ Production Git folders versus user-level Git folders“Restrict production Git folders to run-only access for most users. Allow only admins and Databricks service principals to edit them.”
↩︎ Production Git folders versus user-level Git folders“Production Git folders are created by admins outside user folders, hold deployment branches, and are the source for automated workflows.”
↩︎ Key concept“Restrict production Git folders to run-only access for most users. Allow only admins and Databricks service principals to edit them.”
↩︎ Exam trap 1“When a PR is merged, automation can pull changes into production Git folders using the Databricks Repos API.”
↩︎ Prediction“A user creates a Git folder under /Workspace/Users/<email>/ from a remote repository, works on a user-specific branch, and pushes commits to the remote.”
↩︎ Checkpoint“When ready, create a PR on your Git provider, review with your team, and merge into the deployment branch.”
↩︎ Checkpoint“They should be updated only by automation when PRs are merged into deployment branches.”
↩︎ Checkpoint - 2.
“Switching branches might delete workspace assets when the new branch doesn't contain these assets.”
↩︎ The user flow: feature branches and pull requests“If other users have access to this Git folder, changing the branch also changes the branch for them if they share the same workspace.”
↩︎ Exam trap 2