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?
Advertisement
Answer
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.