How to Restrict Push Access or Hide a Git Branch from Developers in Gitea

In many enterprise Git workflows, it's important to protect critical branches like master or production from unauthorized changes. Especially when using self-hosted platforms like Gitea, teams often want to restrict who can push to protected branches, or in some cases, completely hide the branch from developers.

While Git (and by extension Gitea) does not support native branch-level read access control, there are effective workarounds to restrict and simulate hidden branches securely.

This article will walk through practical steps and strategies to protect or hide a Git branch using Gitea features and Git server controls. We’ll also discuss the benefits, limitations, and the risks involved.

Use Case

Your organization has a private Git server hosted using Gitea, and your main repository (MyAppRepo) has the following branches:

• master (production-ready code)
  
  

• dev, qa, feature/* (active development)
  
  

You want to:

1. Allow only admins to push to the master branch.
   
   

2. Prevent all other users from modifying it.
   
   

3. Optionally make the branch inaccessible or "invisible" to junior developers.
   
   

Step-by-Step Guide

Step 1: Configure Branch Protection in Gitea

Gitea provides a built-in Branch Protection feature that can:

• Prevent force pushes
  
  

• Prevent direct commits
  
  

• Allow only whitelisted users or teams to push
  
  

Instructions:

1. Login to your Gitea web interface as a repository admin.
   
   

2. Navigate to your repo:
   http://gitea.example.org/orgname/MyAppRepo
   
   

3. Go to Settings → Branches.
   
   

4. Click Add New Rule.
   
   

5. Under Protected Branch Name Pattern, enter master.
   
   

6. Set:
   
   

   • Push: Allowlist Restricted Push
     
     

   • Add only admin users (e.g., john.admin)
     
     

   • Force Push: Allowlist Restricted Force Push
     
     

   • Add same admin users
     
     

7. (Optional) Check "Require pull request" to force PR-based changes.
   
   

Result: Only specified users can push to or force-push the master branch.

Step 2: Enforce Further Restrictions with Git Hooks (Optional)

While Gitea protects branches at the UI level, users with SSH access might still try pushing changes if misconfigured. Use Git hooks to enforce access on the server level.

Example pre-receive hook:

#!/bin/bash

while read oldrev newrev refname; do

  branch=$(basename "$refname")

  if [ "$branch" = "master" ]; then

    if [ "$GIT_USER" != "john.admin" ]; then

      echo "Push to 'master' is restricted to admin users only."

      exit 1

    fi

  fi

done

• Location: /home/git/gitea-repositories/orgname/MyAppRepo.git/hooks/pre-receive
  
  

• Note: You must have SSH and shell access to the Gitea host server.
  
  

Step 3: Simulate Hidden Branches via Separate Repositories

Git does not allow per-branch read access restrictions. However, to truly isolate the master branch:

• Move it to a separate private repo, like MyAppRepo-Master
  
  

• Allow access only to admins
  
  

• Use CI/CD (or manual PR) to sync reviewed code from MyAppRepo-Dev
  
  

This effectively hides the production-ready code from developers who don’t need it.

Advantages of This Approach

• Secure Access Control: Prevents accidental or unauthorized changes to critical branches.
  
  

• Audit Trail: Pull requests and review requirements ensure traceability.
  
  

• Production Safety: Reduces deployment risk by controlling what reaches the master branch.
  
  

• Modular Workflow: Developers work in dev and qa, while only admins manage master.
  
  

Limitations

• No native branch hiding: Git doesn’t support hiding branches. Anyone with read access can still list and fetch them.
  
  

• Complexity: Separate repositories and syncing can add maintenance overhead.
  
  

• Server Access Required: Git hooks need shell access to the server, which may not always be allowed.
  
  

Caution

Implementing Git hooks or access policies on a production server involves risk:

• Incorrect hook scripts may block all users
  
  

• Manual syncs between repos can lead to inconsistencies
  
  

• Any misconfiguration may affect CI/CD pipelines
  
  

Proceed only if you understand your Git server’s permission model. Always test in staging first.

Conclusion

Restricting write access to important Git branches like master is a must for teams adopting GitOps or structured DevSecOps pipelines. While Gitea does not support true branch hiding, with branch protection rules, Git hooks, and segmented repositories, you can create a robust, secure, and auditable setup.

This setup ensures that your master branch remains tamper-proof and controlled — a critical requirement in modern CI/CD workflows and production governance.