This post is a part of the DP-800: Developing AI-Enabled Database Solutions Exam Prep Hub.
This topic falls under these sections:
Secure, optimize, and deploy database solutions (35–40%)
   --> Implement CI/CD by using SQL Database Projects
      --> Manage branching, pull requests, and conflict resolution

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

Modern database development follows the same DevOps practices used in application development. Rather than making changes directly in production databases, developers define database objects in SQL Database Projects, store them in Git repositories, collaborate through branches, validate changes with pull requests (PRs), and deploy them using automated CI/CD pipelines.

Branching strategies, code reviews, and conflict resolution are critical to maintaining database quality and enabling multiple developers to work on the same project without interfering with one another. For the DP-800: Developing AI-Enabled Database Solutions exam, candidates should understand how SQL Database Projects integrate with GitHub and Azure DevOps, how branches support parallel development, how pull requests improve code quality, and how merge conflicts are identified and resolved.

Why Branching Matters

Without branching, every developer would modify the same code base simultaneously, leading to:

• Frequent overwriting of changes
• Lost work
• Deployment failures
• Unstable builds
• Difficult troubleshooting

Branching allows developers to:

• Work independently
• Develop multiple features simultaneously
• Fix bugs without affecting ongoing work
• Experiment safely
• Test changes before merging
• Support multiple release versions

Git branches isolate work until it is ready to become part of the main code base.

Git Branch Fundamentals

A branch represents an independent line of development.

Instead of editing the main branch directly, developers create a separate branch.

Example:

main
 ├── feature/customer-search
 ├── feature/new-index
 ├── bugfix/order-total
 └── feature/security

Each branch contains:

• Database objects
• SQL scripts
• Project files
• Build configurations
• Deployment scripts

Developers commit changes to their own branches until the work is complete.

Common Branch Types

Many organizations follow a branching strategy with defined branch purposes.

Main Branch

Usually called:

• main
• master (older repositories)

Characteristics:

• Production-ready
• Stable
• Protected
• Deployable

Direct commits are generally prohibited.

Develop Branch

Some teams maintain a separate develop branch.

Example:

main
↓
develop
↓
feature branches

Develop serves as the integration branch where completed features are merged before being promoted to production.

Feature Branches

Feature branches are created for new development work.

Examples:

feature/add-order-table
feature/customer-report
feature/inventory
feature/security-update

Feature branches should:

• Be short-lived
• Focus on one feature
• Merge back quickly
• Be deleted after merging

Bug Fix Branches

Bug fix branches address defects.

Examples:

bugfix/null-reference
bugfix/index-performance
bugfix/security

Hotfix Branches

Hotfixes repair urgent production issues.

Example:

main
↓
hotfix/login-timeout
↓
production

Hotfixes bypass normal feature development to resolve critical issues quickly.

Branching Strategies

Several branching strategies are commonly used.

GitHub Flow

Simplified workflow:

main
↓
feature branch
↓
Pull Request
↓
Review
↓
Merge
↓
Deploy

GitHub Flow is commonly used for cloud-native and continuous deployment environments.

Git Flow

Git Flow introduces additional branches:

• main
• develop
• feature
• release
• hotfix

This strategy supports complex release cycles but introduces more branch management overhead.

Trunk-Based Development

In trunk-based development:

• Developers create very short-lived branches.
• Changes are merged frequently.
• Continuous integration runs constantly.

Benefits include:

• Smaller merges
• Faster feedback
• Reduced conflicts

Creating a Branch

Typical workflow:

git checkout main
git pull
git checkout -b feature/add-customer-address

The developer now works independently without affecting the main branch.

Keeping Branches Updated

Long-lived branches increase merge conflicts.

Regularly synchronize with the latest changes:

git fetch
git merge main

or

git rebase main

This keeps the feature branch aligned with current development.

Commits Within Branches

A feature branch should contain logical commits.

Good examples:

Add Customer table
Create Orders view
Implement RLS policy
Add clustered index
Fix foreign key constraint

Avoid combining unrelated changes into a single commit.

Push Changes to the Remote Repository

After committing:

git push origin feature/add-customer-address

The branch becomes available for collaboration and review.

Pull Requests (PRs)

A pull request is a request to merge one branch into another.

Example:

feature/add-orders
↓
Pull Request
↓
main

A PR provides:

• Code review
• Discussion
• Automated validation
• Build verification
• Test execution
• Approval workflow

Pull Request Workflow

Typical process:

Developer
↓
Push Branch
↓
Open Pull Request
↓
Automated Build
↓
Automated Tests
↓
Code Review
↓
Approval
↓
Merge
↓
Delete Branch

Benefits of Pull Requests

Pull requests improve quality by allowing reviewers to evaluate:

• SQL syntax
• Naming conventions
• Security
• Performance
• Index usage
• Constraints
• Foreign keys
• Deployment impact
• Maintainability

Multiple reviewers often reduce production defects.

Branch Protection Policies

Production branches should be protected.

Typical policies include:

• No direct commits
• Pull request required
• Minimum reviewer approval
• Successful build required
• Passing automated tests
• Signed commits (optional)
• Status checks

Protected branches reduce accidental deployments and unauthorized changes.

Automated Validation

Many organizations configure PR validation pipelines.

Before merging, the pipeline may:

• Build the SQL Database Project
• Generate a DACPAC
• Run static code analysis
• Execute unit tests
• Validate SQL syntax
• Verify deployment scripts

Only successful builds may be merged.

Merge Strategies

Git supports multiple merge methods.

Merge Commit

Preserves complete branch history.

Main ----A----B------M
          \
           C----D

Squash Merge

Combines all commits into one.

Useful when a feature contains many small commits.

History remains cleaner.

Rebase and Merge

Replays commits onto the latest branch.

Produces a linear commit history.

Some organizations prefer rebasing to simplify repository history.

Merge Conflicts

A merge conflict occurs when Git cannot determine which change should be preserved.

Example:

Developer A:

ALTER TABLE Customers
ADD Phone VARCHAR(20);

Developer B:

ALTER TABLE Customers
ADD PhoneNumber VARCHAR(25);

Git cannot determine which version is correct.

Human intervention is required.

Common Causes of Merge Conflicts

Conflicts often occur when developers modify:

• The same SQL file
• The same stored procedure
• The same table definition
• Shared configuration files
• Database project files
• Static data scripts

The longer branches remain separate, the greater the chance of conflicts.

Conflict Resolution Process

Typical workflow:

Merge Attempt
↓
Conflict Detected
↓
Review Differences
↓
Choose Correct Changes
↓
Edit File
↓
Test
↓
Commit Resolution
↓
Complete Merge

Best Practices for Conflict Resolution

When resolving conflicts:

• Understand both developers’ changes.
• Communicate with teammates if necessary.
• Preserve intended functionality.
• Rebuild the project.
• Run automated tests.
• Validate deployment scripts.
• Review schema differences carefully.

Never resolve conflicts without understanding the impact.

Database-Specific Merge Challenges

Database development introduces unique considerations.

Examples include:

• Simultaneous column additions
• Conflicting index definitions
• Different foreign key changes
• Constraint modifications
• Stored procedure rewrites
• Permission changes
• Seed data updates

Successful merges require understanding both Git operations and database semantics.

Preventing Merge Conflicts

Good practices include:

• Keep branches short-lived.
• Merge frequently.
• Pull latest changes often.
• Break large features into smaller tasks.
• Communicate with team members.
• Avoid editing unrelated files.
• Use atomic commits.
• Review changes before pushing.

Reviewing SQL Changes

Reviewers should examine:

• Table modifications
• New indexes
• Dropped indexes
• Constraints
• Stored procedures
• Views
• Security changes
• RLS policies
• Permissions
• Deployment scripts

Reviewing deployment impact is as important as reviewing SQL syntax.

CI/CD Integration

Branching and pull requests integrate naturally with CI/CD.

Example workflow:

Developer
↓
Feature Branch
↓
Commit
↓
Push
↓
Pull Request
↓
Automated Build
↓
Unit Tests
↓
Generate DACPAC
↓
Approval
↓
Merge
↓
Deployment Pipeline
↓
Development
↓
Test
↓
Production

Azure DevOps Integration

Azure DevOps supports:

• Azure Repos
• Pull requests
• Branch policies
• Build validation
• Release pipelines
• Work item linking
• Reviewer assignment

Branch policies can require:

• Minimum reviewers
• Successful pipeline execution
• Linked work items
• Comment resolution

GitHub Integration

GitHub provides:

• Feature branches
• Pull requests
• Protected branches
• Required reviewers
• GitHub Actions
• Required status checks
• Merge queues
• Code Owners

GitHub Actions can automatically:

• Build SQL Database Projects
• Generate DACPACs
• Execute validation
• Publish build artifacts
• Trigger deployment workflows

Best Practices

Microsoft recommends:

• Never develop directly in the main branch.
• Use descriptive branch names.
• Keep branches short-lived.
• Create focused commits.
• Open pull requests early.
• Require peer reviews.
• Enable automated validation.
• Protect production branches.
• Resolve conflicts carefully.
• Delete merged branches.
• Continuously synchronize feature branches.
• Validate deployments before merging.

DP-800 Exam Tips

Remember the following:

• Feature branches isolate work.
• Pull requests enable code review and automated validation.
• Branch protection prevents unauthorized changes.
• Merge conflicts require manual resolution.
• Short-lived branches reduce conflicts.
• CI pipelines should validate SQL Database Projects before merge.
• SQL Database Projects work naturally with GitHub and Azure DevOps.
• Automated testing should occur before deployment.
• Merge strategies affect repository history but not database functionality.
• Database schema changes should always originate from source-controlled projects.

Practice Exam Questions

Question 1

A development team wants to ensure that database schema changes are reviewed before being merged into the production branch. Which Git feature should they use?

A. Git tags

B. Pull requests

C. Git stash

D. Detached HEAD

Answer: B

Explanation: Pull requests provide a structured review process that allows team members to examine database changes, discuss modifications, run automated validation, and approve changes before merging.

Question 2

A developer needs to implement a new stored procedure without affecting the stability of the production branch. What is the recommended approach?

A. Commit directly to the main branch

B. Modify the production database directly

C. Create a feature branch

D. Disable branch protection

Answer: C

Explanation: Feature branches isolate development work, allowing changes to be tested and reviewed independently before being merged.

Question 3

What is the primary purpose of branch protection rules?

A. Encrypt the Git repository

B. Prevent unauthorized or unreviewed changes to important branches

C. Improve SQL query performance

D. Automatically resolve merge conflicts

Answer: B

Explanation: Branch protection policies enforce requirements such as pull requests, reviewer approvals, and successful build validation before changes are merged.

Question 4

Two developers modify the same table definition in separate branches. Git cannot determine which version should be kept during the merge. What has occurred?

A. Branch rebasing

B. Repository corruption

C. Detached HEAD

D. Merge conflict

Answer: D

Explanation: A merge conflict occurs when Git cannot automatically reconcile competing changes made to the same portion of a file.

Question 5

Which branching strategy typically uses a single production branch with short-lived feature branches and continuous integration?

A. GitHub Flow

B. Waterfall branching

C. Circular branching

D. Centralized version control

Answer: A

Explanation: GitHub Flow emphasizes a simple workflow consisting of feature branches, pull requests, continuous integration, and frequent deployment.

Question 6

What is the greatest benefit of keeping feature branches short-lived?

A. They eliminate the need for pull requests.

B. They reduce the likelihood of merge conflicts.

C. They prevent database backups.

D. They automatically optimize SQL queries.

Answer: B

Explanation: Frequent integration minimizes divergence between branches, making merges simpler and reducing the risk of conflicts.

Question 7

Which activity is commonly performed automatically when a pull request is opened?

A. Database restoration

B. Manual production deployment

C. Build validation and automated testing

D. SQL Server installation

Answer: C

Explanation: CI pipelines commonly build SQL Database Projects, validate SQL syntax, generate DACPACs, and execute automated tests before allowing a merge.

Question 8

A reviewer notices that a pull request includes unrelated changes to multiple database objects. Which best practice was violated?

A. Protected branches

B. Atomic commits and focused feature branches

C. Continuous deployment

D. Repository cloning

Answer: B

Explanation: Feature branches and commits should focus on a single logical change, making reviews easier and reducing deployment risk.

Question 9

After a pull request has been successfully merged into the main branch, what is the recommended next step for the feature branch?

A. Convert it into the production branch.

B. Rename it as “archive.”

C. Continue developing additional unrelated features.

D. Delete the merged branch.

Answer: D

Explanation: Deleting merged feature branches keeps the repository organized and encourages developers to create fresh branches for new work.

Question 10

During conflict resolution, what should a developer do before completing the merge?

A. Skip testing to save time.

B. Delete both conflicting changes.

C. Rebuild the SQL Database Project and validate the merged changes.

D. Commit the conflict markers to the repository.

Answer: C

Explanation: After resolving conflicts, the project should be rebuilt and validated to ensure the merged schema compiles successfully and behaves as expected before the merge is finalized.

Go to the DP-800 Exam Prep Hub main page