Implementing CI/CD · Topic 1 of 2
Git Workflow in Databricks Git Folders
Databricks DEA Git folders: clone a repo, create and switch branches, commit and push, pull, resolve conflicts and open pull requests in the Git provider.
- 5 min
- Git folders were formerly called Databricks Repos; they link a workspace folder to a remote repository.
- Branch create and switch, commit and push, pull, merge, rebase and reset run from the Git dialog.
- Commit and push is one action and needs a commit message.
What it is
A Databricks Git folder (formerly Databricks Repos) is a workspace folder linked to a remote Git repository. Notebooks, Python files, SQL files and configuration in it are versioned in Git, so changes can be branched, reviewed and merged like any other code.
Git folders work with common providers such as GitHub, GitLab, Azure DevOps and Bitbucket. The workspace does the everyday Git operations; review and approval stay in the Git provider.
How it works
Connecting and cloning
Each user first links a Git credential, such as a personal access token or the Databricks GitHub app, in their user settings. It is needed to clone private repositories and to push changes.
To clone, create a Git folder in the workspace and paste the repository URL. Databricks recommends that each developer works in their own Git folder, normally under their user folder, so one person's branch switch does not change another person's files.
The Git dialog
Open the Git dialog from the branch button next to the folder name. It shows the current branch, the changed files with a diff, and the actions you can run.
| Action | What it does |
|---|---|
| Create branch | New branch from a base branch you select; the folder switches to it |
| Switch branch | Checks out another branch; the files in the folder change to match it |
| Commit and push | Commits the selected changes with a message and pushes to the remote in one step |
| Pull | Brings the remote branch's new commits into the folder |
| Merge, rebase, reset | In the dialog's menu; rebase force pushes and reset discards changes, so use them with care |
A commit message is required. For source format notebooks (.py, .sql, .scala, .r), cell outputs are not committed by default, which keeps result data out of the repository.
Branch workflow
The normal pattern is a feature branch per change, never direct commits to the main branch.
When the branch is ready, push it, then open a pull request in the Git provider's interface. The Git folder gets the branch to the remote; the provider handles the pull request, review, approval and merge.
Pulling and conflicts
Pull before you start new work and before you push, so your branch includes others' commits. If the same lines changed on both sides, the dialog shows a merge conflict.
| Conflict choice | Result |
|---|---|
| Edit the file | You combine both versions by hand |
| Keep all current changes | Your version wins |
| Take all incoming changes | The remote version wins |
| Abort | Cancels the operation and discards the conflicting changes |
From Git to production
A Git folder is a development tool. Production runs should come from a reviewed state of the code, not from a developer's working copy.
Two common patterns are a bundle deployed by CI/CD from the merged main branch, and a job task that reads its source directly from a Git provider at a set branch or tag. In both cases nobody edits production files by hand.
How the exam asks about this
- "A developer must work on a new feature without changing main." Create a branch in the Git folder dialog and commit to it.
- "Changes are ready for review by the team lead." Commit and push, then create a pull request in the Git provider.
- "Two engineers edited the same notebook cell and the pull shows a conflict." Resolve the merge conflict in the dialog by editing the file or keeping current or incoming changes.
What to remember for the exam
- Git folders were formerly called Databricks Repos; they link a workspace folder to a remote repository.
- Branch create and switch, commit and push, pull, merge, rebase and reset run from the Git dialog.
- Commit and push is one action and needs a commit message.
- Pull requests are created and reviewed in the Git provider, after the branch is pushed.
- Each developer should use their own Git folder, so branch switches do not affect others.
- Production should run from merged, reviewed code, typically deployed by a bundle in CI/CD.
Switching branches changes the files in that Git folder for everyone who opens it. A shared Git folder that one person switches to a feature branch silently changes what others run; give each developer their own folder.
Common mistakes
Expecting to review and merge inside Databricks. The workspace commits and pushes the branch; the pull request, review and merge happen in GitHub, GitLab, Azure DevOps or Bitbucket.
Committing straight to main. It skips review and breaks the branch workflow the exam expects. Create a feature branch first.
Running production jobs from a developer's Git folder. Any uncommitted edit or branch switch then changes production. Deploy reviewed code with a bundle or point the job at a fixed branch or tag.
Check yourself
Where is a pull request created when working in a Databricks Git folder?
In the Git provider's interface, after the branch has been committed and pushed from the Git folder.
What happens to the folder's files when you switch to another branch?
The folder checks out that branch, so its notebooks and files change to match the branch's content.
Why should each developer have their own Git folder?
Branch switches and uncommitted edits apply to the whole folder, so a shared folder lets one person's changes affect everyone using it.
Topic 1 of 2 in Implementing CI/CD
Test yourself on Implementing CI/CD
The full Databricks Data Engineer Associate question bank has 598 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Databricks. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.