What you will be able to do
- Create a new branch from a chosen base branch in the Git dialog
- Switch branches safely, knowing what happens to uncommitted changes and workspace assets
- Commit and push changes to the remote repository from the workspace UI
- Describe where pull requests are created and merged, and how merged code reaches production Git folders
1.Creating a feature branch
In a Databricks Git folder (a workspace clone of a remote Git repository), branch work happens in the Git dialog.
The documented collaboration pattern starts with a branch. You create a feature branch from main in the Git folders UI, then do your edits there. Databricks recommends that each developer work on their own branch, and the dialog lets you choose any base branch for the new one.
Checkpoint 1 of 7· Put it in order
Put the steps for creating a new branch in a Git folder in order.
- 1.Enter a name for the new branch and select the base branch
- 2.Open the Git dialog
- 3.Click Create Branch
- 4.Click Create
Branch creation starts in the Git dialog, and you name the branch and pick its base before confirming.
“Enter a name for the new branch and select the base branch.”Source: docs.databricks.com
The 'own branch' recommendation has a concrete reason. The current branch belongs to the Git folder, not to each user. If other people have access to the same Git folder in the same workspace, changing the branch changes it for them too. That's why the documented user flow has each developer create their own Git folder under /Workspace/Users/<email>/ and work on a user-specific branch there.
Checkpoint 2 of 7· Exam question
A data engineer wants to create a new branch called `feature/ingestion-fix` from `main` inside a Databricks Git folder, without leaving the workspace UI. What should they do?
Correct answer: B — Open the Git dialog for the Git folder, select Create Branch, enter the branch name, choose main as the base branch, and click Create.
- A. Revision history restores earlier saved versions of a single notebook; it has no connection to Git and cannot create a Git branch.
- B. The Git dialog's Create Branch action lets a user name a new branch, pick a base branch such as main, and confirm creation directly in the workspace UI.
- C. Cloning a Git folder checks out the repository's existing default branch; it does not invent a new branch from a folder's display name.
- D. The bundle configuration file governs deployment targets for Lakeflow Jobs and pipelines, not Git branch creation, and `bundle deploy` does not touch branches.
2.Switching branches and what comes with you
You switch branches with the branch dropdown in the Git dialog. Uncommitted changes go with you as long as they don't conflict with code on the new branch. If you didn't mean to bring them along, discard them before or after the switch.
Switching also changes workspace assets. If the new branch doesn't contain an asset, the switch can delete it. Switching back recreates the asset, but with new IDs and URLs, and that can't be undone. So if you shared or bookmarked assets from a Git folder, confirm they exist on the target branch before you switch. Notebooks lose state when their source code changes, and if you switch to a branch without a notebook, its MLflow experiment data can be lost for good unless you return to the old branch within 30 days.
You can't delete a branch from the Git folders UI; you delete it in your Git provider. Even then, the local copy can stay in the Git folder for up to 30 days. The only way to remove it completely is to delete the repository.
Checkpoint 3 of 7· Check yourself
A dashboard link to a notebook in a Git folder is shared with stakeholders. You switch to a branch that lacks the notebook, then switch back. What is the state of the shared link?
Switching back recreates deleted assets with new IDs and URLs, and that change can't be reversed, so old links and bookmarks stop working.
“Switching back to the current branch recreates the deleted assets with new IDs and URLs. This change can't be reversed.”Source: docs.databricks.com
3.Committing and pushing from the Git dialog
When your edits are ready, you commit and push in one place. In the Git dialog, open the Changes tab and make sure the files you want are selected. Enter a commit message, which is required, plus an optional description. You can compare diffs visually before committing. Then click Commit & Push. That one button commits your work to the working branch and pushes the updated branch to the remote repository, so the dialog has no separate local-commit step.
The commit carries the identity from your Git credential. The credential's email becomes the author and committer email, which is how the provider credits you. Only Git folders with the Public Preview Git CLI access can stage several commits locally before pushing, from a notebook, the web terminal, or Genie Code. In a CLI-enabled folder, the UI's pull, push, and commit run on serverless compute.
Keep two warnings apart. Uncommitted edits that don't conflict follow you when you switch branches. The asset-deletion warning is a different risk: a switch can delete workspace assets that the target branch doesn't contain.
Commit, push, and creating a branch leave the notebook source unchanged, so cell outputs, comments, version history, and widgets are kept. A pull can change the source, and then the Git folder overwrites the notebook and its state is lost.
Checkpoint 4 of 7· Check yourself
Which of these Git operations can cause a notebook in a Git folder to lose its cell outputs and widgets?
State is lost only when an operation changes the notebook source code, and a pull is the operation that can do that.
“Operations like git commit, push, or creating a new branch don't affect source code and preserve notebook state.”Source: docs.databricks.com
What goes into the commit depends on the notebook format. Databricks source format notebooks don't store dashboard information. To preserve dashboards, change the notebook format to .ipynb (Jupyter format), which supports dashboard and visualization definitions by default. To preserve visualization data, commit the notebook with outputs.
Checkpoint 5 of 7· Exam question
A developer working in a Databricks Git folder has several new notebooks that exist only on the current branch and have never been committed. They check out a different branch that does not contain these notebooks. What happens to the uncommitted notebooks?
Correct answer: A — Databricks may delete the uncommitted notebooks from the workspace because the target branch does not contain matching files.
- A. Switching branches in a Git folder can remove workspace assets that the newly checked-out branch does not track, which includes notebooks that were never committed.
- B. There is no automatic stash-and-reapply mechanism for branch switches; uncommitted files are not silently preserved and restored this way.
- C. Databricks does not force a commit or discard before switching branches; uncommitted changes are carried over when they don't conflict, and can be lost when the target branch lacks the files.
- D. No scratch-folder safety net exists for uncommitted work in a Git folder; files that aren't committed are exposed to the branch-switch behavior described above.
Checkpoint 6 of 7· Exam question
A data engineer runs a notebook in a Databricks Git folder, producing table previews and plots, then uses Commit & Push to publish the notebook to the remote repository. A teammate later clones the repository outside Databricks and opens the notebook file. What should the engineer expect regarding the plots and table previews?
Correct answer: C — The plots and table previews will not appear, because notebook outputs are not included in commits when notebooks are saved as source files.
- A. Databricks does not embed rendered cell output into a notebook saved in source format, so the claim of automatic, faithful output embedding is incorrect.
- B. Commit & Push does not create separate binary attachment files for outputs; the commit contains only the source representation of the notebook.
- C. When notebooks are stored in source file formats, execution outputs such as plots and table previews are excluded from what gets committed, so the teammate won't see them.
- D. Exporting to `.dbc` is a separate archive format and is not part of the normal Commit & Push workflow, so it does not change what gets pushed to the remote branch.
4.Pull requests: the hand-off to your Git provider
In Databricks' CI/CD guidance, the pull request belongs to the merge flow. After pushing from a Git folder, users open pull requests, and the documented place to do that is the Git provider. In the walkthrough, after Commit & Push the Git dialog shows a banner with a pull request link that takes you to your provider to create the pull request. Git folders can merge branches themselves (it's in the kebab menu), but the reviewed route is to create the pull request and merge it through your provider.
Checkpoint 7 of 7· Put it in order
Put the documented feature-branch collaboration workflow in order.
- 1.Clone the existing Git repository into your Databricks workspace
- 2.Merge the PR into the deployment branch
- 3.Create a PR on your Git provider and review it with your team
- 4.Edit notebooks and other files in the Git folder
- 5.Commit and push your changes to the remote repository
- 6.In the Git folders UI, create a feature branch from main
Everything up to the push happens in the Databricks UI. The PR, review, and merge happen at the Git provider.
“In the Git folders UI, create a feature branch from the main branch.”Source: docs.databricks.com
Merged code doesn't flow into your personal Git folder. It goes to a production Git folder. An admin creates that folder outside the user folders, checked out to a deployment branch, and it serves as the source for automated workflows. Most users get Can Run on it, and only admins and service principals can edit it. Automation updates it when PRs merge, for example a GitHub Actions workflow or a scheduled job that calls the Repos API. Developers never push there by hand. Their part ends when the PR is merged.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Switching branches in a Git folder throws away your uncommitted edits.Why is that wrong?
Uncommitted changes that don't conflict carry over to the new branch. You have to discard them yourself if you don't want them there.
Covered in Switching branches and what comes with you
2.You can delete an obsolete branch from the Git dialog.Why is that wrong?
You delete branches in the Git provider. Even then, the local branch can stay in the Git folder for up to 30 days.
Covered in Switching branches and what comes with you
3.Pull requests are opened and reviewed inside the Databricks Git dialog.Why is that wrong?
The documented workflow pushes from the Git folder, then creates, reviews, and merges the PR on your Git provider.
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
“Databricks recommends that each developer work on their own branch.”
↩︎ Creating a feature branch“Merge flow: After pushing from a Git folder, users open pull requests (PRs).”
↩︎ Pull requests: the hand-off to your Git provider“They should be updated only by automation when PRs are merged into deployment branches.”
↩︎ Pull requests: the hand-off to your Git provider“When ready, create a PR on your Git provider, review with your team, and merge into the deployment branch.”
↩︎ Prediction“In the Git folders UI, create a feature branch from the main branch.”
↩︎ Checkpoint - 2.
“changing the branch also changes the branch for them if they share the same workspace.”
↩︎ Creating a feature branch“Switching branches might delete workspace assets when the new branch doesn't contain these assets.”
↩︎ Switching branches and what comes with you“can remain present in the associated Git folder for up to 30 days after you delete the remote branch”
↩︎ Switching branches and what comes with you“Commit your work to the working branch and push the updated branch to the remote Git repository.”
↩︎ Committing and pushing from the Git dialog“Add a commit message and optional expanded description for your changes.”
↩︎ Committing and pushing from the Git dialog“Uncommitted changes on the current branch carry over and show as uncommitted changes on the new branch”
↩︎ Exam trap 1“Enter a name for the new branch and select the base branch.”
↩︎ Checkpoint“Uncommitted changes on the current branch carry over and show as uncommitted changes on the new branch”
↩︎ Prediction“Switching back to the current branch recreates the deleted assets with new IDs and URLs. This change can't be reversed.”
↩︎ Checkpoint - 3.https://docs.databricks.com/aws/en/repos/limitsOfficial docs
“Switching to a branch that doesn't contain the notebook risks losing the associated MLflow experiment data.”
↩︎ Switching branches and what comes with you“git pull can change notebook source code, requiring Git folders to overwrite the existing notebook.”
↩︎ Committing and pushing from the Git dialog“To preserve visualization data, commit the notebook with outputs.”
↩︎ Committing and pushing from the Git dialog“To delete a branch, you must work in your Git provider.”
↩︎ Exam trap 2“You can also create a pull request and merge through your Git provider.”
↩︎ Exam trap 3“Operations like git commit, push, or creating a new branch don't affect source code and preserve notebook state.”
↩︎ Checkpoint - 4.
“For Commit message (required), enter Updated comment.”
↩︎ Committing and pushing from the Git dialog“Click Commit & Push.”
↩︎ Committing and pushing from the Git dialog“Click the pull request link in Create a pull request on your git provider in the banner”
↩︎ Pull requests: the hand-off to your Git provider