Explanation:
Databricks Repos follows standard Git conventions. If a user does not have write access to a protected branch like main, the correct workflow is to create a new branch, commit changes to it, push that branch to the remote provider, and then use the Git provider's interface (e.g., GitHub, GitLab, Azure DevOps) to open a Pull Request (PR).
Why other options are incorrect:
main is protected, the push will be rejected.git pull operation updates the current branch; it does not automatically create or check out a new branch for you to push to.Ultimate access to all questions.
A data engineer has configured their Databricks Repos credentials and cloned a remote Git repository into their workspace. They find that the main branch is the only branch currently visible and that they lack the permissions to modify it directly.
What is the recommended workflow for this developer to share their code updates while ensuring they do not overwrite their teammates' work or violate branch protections?
A
Merge all local differences using the Databricks Repos UI and submit a pull request directly to the remote repository's main branch.
B
Pull changes from the remote repository using Databricks Repos, then commit and push changes to a branch that is automatically generated as a result of the pull operation.
C
Create a new branch within Databricks Repos, commit the local changes to this branch, and push the branch to the remote Git repository.
D
Create a fork of the remote repository using the Databricks Repos interface, commit all changes, and then submit a pull request to the original repository.
No comments yet.