Private branches for public repositories

[erkinalp]

Some open source projects have companion proprietary projects sharing lots of code and issues. Along with appropriate access control in issues and PRs, this will help deduplication.

[cirosantilli]

Does the proprietary code have issues from users which cannot see the source?

Would you also need a per issue public / private permission?

[erkinalp]

Yes. However, developers will have to care not to reveal closed source code in a public comment.

[Lemongrass3110]

+1 for this. At times like these it would be better to have a feature like this(PR/branches for non public exploits).

[nottrobin]

I really want this feature. But neither Bitbucket not Gitlab seem to offer it, so I'm wondering if it's deeply incompatible with the way git works?

[ProLoser]

I think it should be private forks of public repos, but that may have some conflicts with licensing issues.

[ChrisRackauckas]

This is really big for academics who cannot release code until after publication, but may be implemented a new algorithm by modifying an existing one (especially when it's a new addition to one's own specialized package).

[ProLoser]

While you can't really fork and change privacy, you CAN 'fake' a fork by simply creating a 'new' private repo and pushing all of the public history to it. You lose the cross-repo Pull-Request GUI but you can still use GIT locally to do all the updating. It's the same as having 2 remotes (one is public, one is private). Just make sure not to push to the public one.

[brittanydionigi]

I would absolutely die and go to heaven if private branches became a thing. I'm writing curriculum for Turing School and a lot of our lessons come with tutorial repos where we want a public 'begin' branch that just contains boilerplate for students to build off of to complete the tutorial. It would be amazing to have a private branch for the completed version so that instructors could use it for reference, but students wouldn't be able to look ahead and copy the completed example instead of doing the work.

[Alex-Tideman]

I also teach at Turing School of Software and WOULD LOVE THIS FEATURE. Having the ability to store private branches on a repo for answers would be so nice so our projects stay well organized, we won't need a million repos, and the students can't get free answers.

[jsocol]

I used to maintain an open source security tool, private issues and branches would have been huge, since currently any issue, branch, or PR is potentially immediate disclosure of a serious issue.

[stacimcwilliams]

👍

[tmikeschu]

YAS

[mihuss]

such a useful feature... it's really sad that it is not offered / supported currently :(

[micahstubbs]

👎 feel like this confuses the community about what is open and what is not.

separate private repos and build tools to combine them with OSS dependencies is the solution I've seen used in practice.

[justindocanto]

Absolutely need this.

For example, right now i need to add a branch for our dev-only tools & reporting for a project that aren't intended to be public. Yes we can make another repo but the tools integrate heavily with the master branch and it would be ideal to have it simply be a branch

[afbarnard]

I am also thinking about something like this from a research point of view where code would be kept private until publication. I would be fine with a public fork downstream from a private repo if that would work. This would also seem to be a solution for the freemium model of software. Or maybe it should be the other way around: a private fork downstream from a public repo. Does anybody have experience with this?

Update: It appears that a common solution is to have both public and private repos and to set up one's local repo to track both. Branches and files can be specific to either the public or private repo, and can be shared between them, although this involves some careful manual management. I gather that this works whether one repo is a fork of the other or not. Here are some references:

• Overview of public and private branches
• Explanation of remote branches
• Synchronizing forks

[paaddyy]

I agree, it would be awesome if you could create private branches on public repos 😍 git checkout -b -p XXX (e.g. a flag for private) would be an amazing command imo 😄

[eosfor]

+1

[grant]

This would help us with sharing early-access code for new @gsuitedevs APIs with developers before the API is launched.

All of our code is organized by language (i.e. node-samples). We currently have private ({product}-api-samples) repos, but we'll have split these into our 11 public language-based sample repos when the API is public.

Although, I could see how the ACL controls could be a bit confusing.

[marcussacana]

Well, Nothing yet?

[nottrobin]

@paaddyy: git checkout -b -p XXX (e.g. a flag for private) would be an amazing command imo smile

When you do git checkout -b you're creating a branch within the local git repository in your folder on your computer. At that point, it's not shared anywhere. The cloned repository on your computer has no concept of public or private. Fundamentally, Git, the command-line tool, has no concept of GitHub, and therefore also has no understanding of public or private.

Only once you push your repository to GitHub does public/private have any meaning.

The place where the git CLI command and GitHub functionality intersect is the hub project. If GitHub were to ever support private branches, it would then probably make sense for hub to add functionality to interact with private branches.

[thorade]

https://twitter.com/github/status/1131473309470789632

[itsvinayak]

really in need of this

[ErikSRoth]

This would be a great feature!!! +1

[saart]

Yeah! +1 to that!

[adithyabsk]

+1

[antoniocavalcante]

+1

[JamesNewton]

We really need this!

[KevinDuganJr]

This would be pretty nice to have.

[nick-dolan]

+1

[OzzieFZI]

+1

[ma-sadeghi]

+1

[jamesonwilliams]

I also think that this would be groovy.

[singlerider]

👍

[MatroseN]

This would be a great addition

+1

[koulanurag]

+1

[ghost]

+1

[bohdantverdyi]

+1

[mikkelee]

+1

[ThizThizzyDizzy]

+1

[abhishekyana]

+1 Desperately need this feature.

[ObscureBug]

+1 Really need this feature.

Tools are supposed to make life easier! Not having this feature makes development harder, particularly on dependent packages, as it requires extra private repos, overhead and tracking - which is all just a waste of valuable time.

[RashminDungrani]

+1

[alexcombessie]

also interested in this feature

[cernec1999]

This feature would be very helpful! Especially in vulnerability research community, where we hide exploits until a disclosure period has passed.

I -could- create a private fork of the repo in question, but that seems overkill for what should be such a simple task.

Is it something in git internals that prevents this?

[ObscureBug]

This feature would be very helpful! Especially in vulnerability research community, where we hide exploits until a disclosure period has passed.

I -could- create a private fork of the repo in question, but that seems overkill for what should be such a simple task.

Is it something in git internals that prevents this?

The problem is that you can't (in github) create a clone of one of your existing repos, otherwise create public and private repos that are related would create a workaround. You can't even have multiple forks of an upstream repo (on github).

[catmade]

+1

[ObscureBug]

Sadly, this enhancement didn't make it to the publicly announced product roadmap.

[MaxKlaxxMiner]

I have been paying for github pro for several years now. Originally for the feature "private repositories" and now simply as a donation. There are several "branch protection rules" in the settings here, but "private branches" would still fit nicely. :-)

For example, it is a bit tedious to copy test photos manually between home, office and members because there is no final copyright release yet. (it is not yet clear which pictures will be published in the future)

+1

[DarthXoc]

+1, can't believe this feature doesn't exist already!