nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Locking down access to a repository branch

Dawn Garner

Hi all,

Due to confidential nature of a new project (must be approved and sign NDA to work on it), we need a way to lock down a branch so that it can't be viewed by some of the members of our development team. This means not even read access. I have not found a way to do this other than creating a fork (which then adds a number of additional complexities and unknowns that we are not excited about). Is there a workaround that anyone has come across? Some way to even set up password access for a branch or something?

Suggestions are much appreciated.

Thanks,

Dawn

Accepted answers

Julius Davies _GitBoost_com_

You cannot have branches in Git that are invisible to some people.

You'd have to implement this by using a fork.

Question: would this secret branch ever merge back into master or other mainline branches?

All comments

Julius Davies _GitBoost_com_

You cannot have branches in Git that are invisible to some people.

You'd have to implement this by using a fork.

Question: would this secret branch ever merge back into master or other mainline branches?

Dawn Garner

Thanks so much for the info - was afraid of that.

Yes, we do need to merge it back in to the master upstream branch once the project is completed. Plus we have other ongoing projects happening off of that master upstream branch. This is the nightmare scenario I was hoping to avoid.

I haven't found much information online yet on how to efficiently handle this issue, but I would think other companies out there would have this same need - was hoping to find a creative workaround someone else had figured out.

Julius Davies _GitBoost_com_

The moment you merge back into the original 'master' branch, all the work (up to the point of the merge) will become visible to everyone in the original repository. Are you okay with that?

Is the main problem keeping the fork's master in-sync with upstream master? To keep the fork up to date, I would recommend the following setup:

1. In the fork's config, make 'master' read-only except for a special service account (don't let the secret project team push or merge to 'master').

2. Setup a clone on a restricted server somewhere that has access to both upstream and the fork and has the special "service account" credentials to push to fork/master. Something like this:

git clone --bare [original-clone-url]
cd [original-clone.git]
git remote add fork [fork-clone-url]

3. On that same restricted server setup a cron job that runs every minute and just does the following over and over again, once per minute!

git fetch origin
git push --force origin/master:fork/master

That will keep the fork's 'master' always identical to upstream's master. The secret project work would need to happen on a different branch, but they can take merges from fork/master or rebase on top of fork/master whenever they like. (And they should probably do so often).

Good luck!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

bitbucket

bitbucket-cloud

permission

branch