4

Background

I'm working with a large team using 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 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 provides a one-button delete feature for this once the code review is complete).

Question

Is there a way to configure our company 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?

Yusef Maali
  • 1,844
  • 2
  • 20
  • 25
Cloud
  • 17,212
  • 12
  • 64
  • 137
  • 1
    Does github allow you to push to different namespaces like `refs/WIP/`. If so, you could still push/fetch to/from these refs but they would not show up in `git branch --all` at all. – Mort Oct 20 '17 at 18:19
  • @Mort I couldn't find anything on the subject. – Cloud Oct 20 '17 at 19:35

3 Answers3

3

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.

Yusef Maali
  • 1,844
  • 2
  • 20
  • 25
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.

larsks
  • 194,279
  • 34
  • 297
  • 301
  • Exactly. There is no law that says you have to push everything everywhere, or fetch everything from anywhere. If you want an only-the-currently-important-refs repo, make one. If there isn't a global only-the-important-bits repo, make one locally by configuring the fetch to only get what you care about. – jthill Oct 20 '17 at 20:20
1

The first answers are good. If you can fork repositories and use pull-requests or just keep the branches for yourself, do it.

I will however put my 2 cents in case you are in my situation : a lot of WIP branches that you have to push to a single repository since you work on multiple workstations, don't have fork possibilities, and don't want to annoy your fellow developers.

Make branches starting with a specific prefix, i.e. wip/myuser/, fetch from / push to a custom refspec, i.e. refs/x-wip/myuser/*.

Here is a standard remote configuration after a clone:

[remote "origin"]
        url = file:///c/temp/remote.git
        fetch = +refs/heads/*:refs/remotes/origin/*

To push branches starting with wip/myuser/ to refs/x-wip/myuser/, you will add:

push = refs/heads/wip/myuser/*:refs/x-wip/myuser/*

This will however override the default push rule for the normal branches. To restore it, you will add:

push = refs/heads/*:refs/heads/*

Finally, to fetch you WIP branches that are now outside the conventional refs/heads/* refspec, you will add:

fetch = +refs/x-wip/myuser/*:refs/remotes/origin/wip/myuser/*

You will end up with this 2nd remote configuration:

[remote "origin"]
        url = file:///c/temp/remote.git
        fetch = +refs/x-wip/myuser/*:refs/remotes/origin/wip/myuser/*
        fetch = +refs/heads/*:refs/remotes/origin/*
        push = refs/heads/wip/myuser/*:refs/x-wip/myuser/*
        push = refs/heads/*:refs/heads/*

(Git evaluates fetch / push rules from the top to the bottom, and stops as soon as one matches; this means you want to order your rules from the most to the less specific rule.)

People using the standard remote configuration will only fetch branches from refs/heads/*, while you will fetch branches from both refs/heads/* and refs/x-wip/myuser/* with the 2nd configuration.

When your branch is ready to be "public", remove the wip/myuser/ prefix.

The refspec internal documentation was useful to make it.

Please note that once you have push rules in your remote configuration, running the command...

git push

... with no arguments will no longer only push your current branch, nor use any strategy defined with the push.default configuration. It will push everything according to your remote push rules.

You will either need to always specify the remote and the branch you want to push, or use an alias as suggested in this answer.

kagmole
  • 1,613
  • 10
  • 22