Part 3 : Version Control Security: Branch Protections

Branches in Git are like “lanes” of code. Some lanes are safe for experiments (feature branches), but others are critical highways (main, develop, release branches).

If someone pushes bad code straight into main, it could break production in seconds. That’s why branch protections exist: to put guardrails around your most important branches.

-------------------------------------------------------------------------------------------------------------

GitHub Branch Protections

On GitHub, branch protections are very customizable. Here are the most important options:

• Require Pull Request Reviews (✅ Always Enable)

  • At least 1–2 people must review before merging.

  • Stops “lone wolf” coding straight into production.

    
    

• Include Administrators (✅ Enable this!)

  • By default, admins can bypass protections.

  • If their account or SSH key is compromised, attackers can push directly into main.

  • Enabling this forces even admins to follow the rules.

• Require Signed Commits (Optional, but Strong)

  • Developers must sign commits with GPG keys.

  • Prevents impersonation or “mystery commits” from unverified users.

• Disallow Force Pushes (✅ Keep Disabled)

  • Prevents someone from overwriting history with git push --force.

  • Protects from lost work or sneaky backdoor commits.

• Disallow Deletions (✅ Keep Disabled)

  • No one should be able to delete main or develop. Period.

In short: On GitHub, always enforce reviews, admin restrictions, no force pushes, no deletions. Signed commits are a bonus layer.

-------------------------------------------------------------------------------------------------------------

GitLab Branch Protections

GitLab’s rules are simpler but still powerful:

• Allowed to Merge:

  • Decide which group(s) can merge changes.

  • Typically: “Maintainers” for main, “Developers” for develop.

• Allowed to Push:

  • Should always be set to No One for protected branches.

  • This forces Merge Requests only, which means reviews and checks must pass.

• Require Code Owner Approval (Premium Feature):

  • Lets you require approvals from the owner of a specific file or directory.

  • Example: Only security engineers can approve changes to auth/.

  • Great for granular control, but requires GitLab Premium.

In short: In GitLab, enforce No direct pushes, only MRs, proper role-based merging, and (if available) CodeOwner approvals.

-------------------------------------------------------------------------------------------------------------

Azure DevOps Branch Policies

Azure DevOps calls them Branch Policies, and they’re pretty flexible:

• Require Minimum Number of Reviewers:

  • Define how many approvals are needed before merge.

  • Typically 2 reviewers for critical branches.

    
    

• Disallow Self-Approval:

  • Prevents developers from approving their own PRs.

  • Helps enforce “separation of duties.”

    
    

• Block Last Pusher from Approving:

  • The person who made the last commit can’t count as a reviewer.

  • Stops someone from sneaking in changes and approving themselves.

    
    

• Reject if Any Reviewer Votes No:

  • Default: if someone rejects, the PR is blocked.

  • You can override this, but generally safer to block unless explicitly approved.

    
    

• Reset Votes on New Commits:

  • If new code is pushed after a review, approvals reset.

  • Ensures fresh eyes on fresh changes.

    
    

In short: Azure DevOps gives you more knobs to tune — use them to enforce real reviews, prevent self-approvals, and reset approvals if new code is added.

-------------------------------------------------------------------------------------------------------------

Comparing GitHub vs GitLab vs Azure DevOps

Feature	GitHub	GitLab	Azure DevOps
Require Reviews	✅ Yes	✅ Yes (via MRs)	✅ Yes
Admin Restrictions	✅ Yes	❌ Limited	✅ Yes
Signed Commits	✅ Yes	❌ Not built-in	✅ Yes (via policy)
Force Push Protection	✅ Yes	✅ Yes	✅ Yes
Branch Deletion Protection	✅ Yes	✅ Yes	✅ Yes
Code Owner Rules	✅ Yes	✅ Premium only	✅ Yes
Advanced Review Rules	⚠️ Basic	⚠️ Limited	✅ Very Flexible

-------------------------------------------------------------------------------------------------------------

Best Practices (No Matter the Platform)

1. Protect main and develop (and release branches if used).

2. No direct pushes — all changes via PR/MR.

3. Always require at least 1–2 reviewers, preferably more for sensitive code.

4. Don’t let devs approve their own changes.

5. Restrict admins — they should follow the same rules.

6. Disable force pushes and deletions on critical branches.

7. Use Code Owners for sensitive areas (auth, payments, infra).

   
   

Branch protections = “guardrails” for your repo.They don’t just enforce process, they reduce insider threats, mistakes, and even admin account compromises.

---------------------------------------------------Dean---------------------------------------------------