Protected Branch and Preventing Direct Pushes to main

1. What is a Protected Branch?

A protected branch is an important Git branch that has repository rules or policies applied to control how changes can be made to it.

Typically, branches such as:

main
develop
release

may be protected.

The main purpose is to prevent developers from bypassing the team's normal development process.

Instead of:

Developer
    |
    | git push
    v
  main

the team can enforce:

Developer
    |
    v
Feature Branch
    |
    v
Pull Request
    |
    v
Code Review
    |
    v
CI / Status Checks
    |
    v
Approval
    |
    v
  main

Protection is provided by repository-hosting platforms such as GitHub and Azure DevOps. It is not simply a local Git setting.

2. Simple Example

A developer creates a feature branch:

git switch -c feature/login

Makes changes:

git add .
git commit -m "Add login feature"

Pushes the feature branch:

git push -u origin feature/login

Then creates a Pull Request:

feature/login
      |
      | Pull Request
      v
     main

After review and required checks:

PR Approved
    +
CI Passed
    |
    v
Merge into main

The developer does not directly push application changes to main.

3. What Happens Without Branch Protection?

Suppose a developer runs:

git switch main
git pull origin main

# make changes

git add .
git commit -m "Update login"
git push origin main

Without server-side protection and with sufficient repository permissions, the push could update main directly.

That means the developer could potentially bypass:

• Pull Request review
• Required reviewers
• Build validation
• Unit tests
• Other required checks

This can be risky for an important production branch.

4. How Do You Prevent Direct Pushes?

You configure protection on the remote repository.

GitHub

GitHub supports repository rules such as rulesets and branch protection settings.

For main, a team can configure rules requiring changes to go through a Pull Request and requiring approvals/status checks.

Conceptually:

main
 |
 +--> Require Pull Request
 |
 +--> Require approvals
 |
 +--> Require status checks
 |
 +--> Restrict/bypass permissions
 |
 +--> Merge only when requirements pass

Now, if an unauthorized developer attempts:

git push origin main

the remote repository rejects the update according to the configured rules.

The developer should instead push:

git push origin feature/login

and create a PR.

5. Azure DevOps

In Azure DevOps, the same goal is commonly achieved with branch policies plus branch security permissions.

For example, on main you may configure policies such as:

Minimum reviewers       : 2
Build validation        : Required
Comment resolution      : Required
Required reviewers      : As needed

But there is an important distinction:

Branch policies control PR requirements, while branch security permissions control whether users can directly push to the branch.

To prevent ordinary developers from directly pushing to main, their branch permissions must be configured appropriately—for example, not granting the ability to bypass the PR/policy workflow.

The desired flow becomes:

Developer
    |
    | Push
    v
feature/login
    |
    | Create PR
    v
main
    |
    +--> Reviewers
    |
    +--> Build Validation
    |
    +--> Other Policies
    |
    v
Merge

6. What Happens When a Direct Push Is Rejected?

Suppose a developer tries:

git push origin main

The local Git client sends the proposed update to the remote server.

Local Repository
      |
      | git push origin main
      v
Remote Repository
      |
      v
Check branch rules/permissions
      |
   +--+--+
   |     |
Allowed Rejected

If the repository's rules do not permit that direct update:

git push
   |
   v
Remote checks protection
   |
   v
Push rejected

The important point is that protection is server-side.

A developer cannot normally bypass the remote repository's protection merely by using another local Git command.

7. Protected Branch vs Normal Branch

For example:

feature/login
     |
     | Developer can push commits
     v
feature/login
     |
     | PR + Review + CI
     v
    main
  (protected)

8. Practical Team Scenario

Suppose five developers work on an application.

Without protection:

Developer A -----\
Developer B ------\
Developer C -------> main
Developer D ------/
Developer E -----/

Anyone with sufficient write permission could potentially push directly.

With protection:

Developer A --> feature/a --\
Developer B --> feature/b ---\
Developer C --> feature/c ----> Pull Requests
Developer D --> feature/d ---/       |
Developer E --> feature/e --/        v
                               Review + CI
                                    |
                                    v
                                  main

This gives the team a controlled path for changing main.

9. Can Administrators Bypass Protection?

Potentially, yes.

GitHub and Azure DevOps have administrative/bypass permissions that can allow certain authorized users or service accounts to bypass some protections.

Therefore, branch protection does not necessarily mean:

"Nobody can ever directly modify main."

It means the repository is configured to enforce specific rules for the users and roles covered by those rules.

A good practice is to keep bypass permissions limited.

10. Key Points

• A protected branch has rules controlling how changes can enter it.
• main is commonly protected.
• Developers normally work on feature branches.
• Changes reach main through a Pull Request.
• PRs can require:
  • Code review
  • Minimum approvals
  • Successful builds
  • Unit tests
  • Status checks
• Protection is enforced by the remote repository platform, not by the developer's local Git installation.
• In GitHub, use branch protection/rulesets and appropriate repository permissions.
• In Azure DevOps, use branch policies together with branch security permissions to enforce the desired workflow.
• Restrict bypass permissions to authorized users/services.
• Protecting main reduces the risk of unreviewed or unvalidated code entering an important branch.

11. Interview Answer

A protected branch is an important branch, such as main, that has repository rules or policies controlling how changes can be made to it. To prevent developers from directly pushing to main, I configure server-side branch protection and permissions in GitHub or Azure DevOps. Developers work on feature branches, push those branches, and create Pull Requests. The PR can require code-review approvals and successful CI checks before it is merged into main. This prevents developers from bypassing the team's review and validation process.