A data engineer has finished work on a feature branch inside a Databricks Git folder linked to a hosted Git provider. The team requires the change to be reviewed before it reaches the main branch. Which sequence reflects how the workspace UI and the Git provider divide that work?
- ACommit and push the branch from the Git folder dialog, then open, review and merge the pull request in the linked Git provider, which the dialog links out to. Correct
- BPush the branch from the Git folder dialog and then run a merge command in a notebook cell, so that the branch is combined into main from inside the workspace.
- CCreate the pull request from the Git folder dialog, which raises the request inside the workspace and merges the branch as soon as a reviewer approves it there.
- DAsk a workspace administrator to merge the branch from the admin settings page, because branches in Databricks Git Folders are governed at the account level.
Why A is correct: Correct, because Databricks Git Folders handles the branch, commit and push, while the pull request itself lives in the provider that hosts the repository.
Why B is wrong: It is tempting because notebooks can run shell commands, but a Git folder is not a general command line checkout and merging this way bypasses the review the team requires.
Why C is wrong: Plausible because the dialog does mention pull requests, but the workspace hosts no review surface of its own; approval and merge belong to the linked provider.
Why D is wrong: Tempting for teams used to central control, but admin settings govern the Git provider integration and credentials, not the branch history of a linked repository.