How to use git namespace to hide branches

问题:

Background

I'm working with a large team using git for version control. The normal flow is:

• People selecting a ticket from the "backlog queue".
• Working on the issue via a local branch (i.e. git checkout -b my_feature_branch).
• Making several commits as they go (i.e. git commit).
• Pushing local changes to a remote branch in order to "backup" their work so it lives on more than one machine, in case the laptop is damaged or stolen (i.e. git push -u origin my_feature_branch).
• Eventually creating a code review on our private github page, and doing a squashed merge from the feature branch to master.

In addition to the remote feature branches created by employees on an as-needed basis, we have several dozen release branches that are used to create the "gold builds" we ship to customers, i.e. 1.00, 1.01, 2.00, 2.01, 2.02, etc.

---

Problem

Some developers have begun to complain that there are too many branches, and I tend to agree. Some developers haven't been diligent about cleaning up old branches when they are no longer needed (even though github provides a one-button delete feature for this once the code review is complete).

---

Question

Is there a way to configure our company github deployment so that, when people use git branch via the CLI:

• Only our "important/release/gold" branches appear.
• The one-off developer (temporary) branches only appear via git branch -a?

The main goal of this is to reduce clutter.

Edit: I found a similar question, but the only answer is not at all applicable (don't use remote branches), which violates my key constraint of allowing people to push to remote branches as a form of data backup. The concept of private namespaces, as hinted by @Mort, seems to be exactly what I'm looking for. Now, how do I accomplish that?

回答1:

Long story short: you can - but it may be a bit tricky.

You should use the namespace concept (give a look here: gitnamespaces)

Quoting from the docs:

Git supports dividing the refs of a single repository into multiple namespaces, each of which has its own branches, tags, and HEAD. Git can expose each namespace as an independent repository to pull from and push to, while sharing the object store

and

Storing multiple repositories as namespaces of a single repository avoids storing duplicate copies of the same objects, such as when storing multiple branches of the same source.

---

To activate a namespace you can simply:

export GIT_NAMESPACE=foo

or

git --namespace=foo clone/pull/push

When a namespace is active, through git remote show origin you can see only the remote branches created in the current namespace. If you deactivate it (unset GIT_NAMESPACE), you will see again the main remote branches.

---

A possible workflow in your situation may be:

Create a feature branch and work on it

export GIT_NAMESPACE=foo
git checkout -b feature_branch
# ... do the work ...
git commit -a -m "Fixed my ticket from backlog"
git push origin feature_branch # (will push into the namespace and create the branch there)

Merging upstream

unset GIT_NAMESPACE
git checkout master
git pull (just to have the latest version)
git merge --squash --allow-unrelated-histories feature_branch
git commit -a -m "Merged feature from backlog"
git push # (will push into the main refs)

---

The tricky part

Namespace provides a complete isolation of branches, but you need to activate and to deactivate namespace each time

Pay attention

Pay attention when pushing. Git will push in the current namespace. If you are working in the feature branch and you forgot to activate the namespace, when pushing, you will create the feature branch in the main refs.

回答2:

It seems as if the simplest solution here, since you're using GitHub and a pull-request workflow, is that developers should be pushing to their own fork of the repository rather than to a shared repository. This way their remote feature branches aren't visible to anybody else, so any "clutter" they see will be entirely their own responsibility.

---

If everything lives in a single repository, another option would be to set up a simple web service that receives notifications from github when you close a pull request (responding to the PullRequest event). You could then have the service delete the source branch corresponding to the pull request.

This is substantially less simple than the previous solution, because it involves (a) writing code and (b) running a persistent service that is (c) accessible to github webooks and that (d) has appropriate permissions on the remote repository.