I have a private Github repository that receives contributions from multiple groups. I'd like that some of the contributions of Group A in an experimental branch would remain hidden for a certain time from Group B. Group A has already pushed those branches on Github. So I was thinking that Group A could make a fork bringing all his branches into their fork.

Then, what happens in the future of the fork if I delete those branches made by Group A in the source repository? For example, if Group A pulls changes from the source repository, would their branches be deleted?

Is there a way I can delete those branches in the source repository while ensuring they would remain alive in the fork of Group A?

CodePudding user response：

TL;DR

You're talking about hiding things with hidden names, having them come into existence and then go away, and asking about all of that in a weird way. The answer is therefore both no and yes. You can do what you want; it won't really matter. What you need to know is how it actually works.

Long

Git isn't actually very interested in branches. Branches are not the point: it is commits that matter. And in fact, the word branch doesn't really mean anything in Git—or to put it another way, it means at least two or three different things, so that nobody knows what you mean if you just say "branch". We need some additional context, to figure out which of the many meanings of "branch" you actually meant.

What you meant here is clear enough though: you meant branch names, and by being sufficiently specific we do get some answers:

• A GitHub "fork" is a kind of git clone where the cloning operation happens entirely on GitHub. It does a few extra things behind the scenes, too.

• A regular Git clone works by copying all of the commits and none of the branch names. This matters a lot because you're concerned about branch names—but you shouldn't be so concerned about branch names! You should mostly be concerned instead about the commits.

Let's start with the regular git clone operation, since a "GitHub fork" style clone is so closely related, but it's in the clones on one's laptop (or similar computer) that one will actually do work.

Understanding repositories and clones

A Git repository is, at its heart, two databases:

• One database—usually much larger—contains Git's commits and other objects (the objects needed by the commits, and perhaps annotated tag objects that we use to attach a little more information to releases, for instance). This database is indexed by object hash IDs (or OIDs, which stands for Object IDs: Git changed terminology when SHA-1 began to be supplanted, but you'll still see these called "SHA hashes" or similar). These hash IDs are incredibly bad for humans, so for the most part we just don't use them. But Git needs them. So:

• The other database, usually much smaller, contains names: branch names, tag names, remote-tracking names, and all sorts of names. (Git's current implementation of this database is poor, which leads to various problems with mixed-case names on Windows for instance, but that's just a Small Matter of Programming to fix: the fix has been underway for at least 2 or 3 years and will probably be out within a few decades.