问题
I've taken over a big git repository with lots of branches that no one really seems to know what they are all about. Is there any way to put branches in some kind of grouping or folder so that they are still there but not necessarily listed? To make the important branches easier to spot.
Edit: I want to be able to distinguish between the branches that I work with and the branches that don't really make sense to me but still can't be deleted.
回答1:
Delete the branches.
If nobody knows what they are, and nobody has laid claim to them, it's not likely anyone will. Like hoarding old newspapers "just in case", they just get in the way of getting things done. Let it go. Particularly if they're rather behind and likely to be a PITA to update.
Deleting them will tell you very quickly if anything or anyone was relying on them. For a tiny amount of controllable pain you will have resolved a great uncertainty. And people will learn not to leave important stuff just lying around cluttering everything up.
Branches are ephemeral things in Git and easy enough to restore in various ways. There are simple things you can do to make this process easier and more robust. This is mainly to make your devs happier with the idea of deleting branches.
Make them into tags
In Git, tags are basically exactly the same as branches, they're just a label on a commit. The difference is they don't move. Make a tag on the branch tip, then delete the branch tip. The tag will reference the commits and keep them from being garbage collected.
git tag <tag> <branch>
git branch -d <branch>
You can combine this with Maor's answer and organize the tags into a directory like archived_branches/.
If somebody wants to work on that archived branch, they can create a branch from the tag and delete the tag.
git checkout -b <tag> <branch>
git tag -d <tag>
This is an extremely cheap process in Git.
Eventually when nobody's used these archived tags in a while, you can delete them as dead. Agree upon a date when you make the tag archive. Mark it on a shared calendar.
Salvage the branch content
Be sure to examine the branch content for anything salvageable. If there is you can make it an active branch, or cherry pick the useful bits.
Get the people who want to keep old branches around "just in case" to do this work.
Delete everything that's been merged
You can check what branches have been merged with master git branch --merged master. Delete merged branches. The connections between the commits will retain what was a branch, and the merge commit will retain what that branch was. For example...
A - B - C --------- G - H - I [master]
\ /
D - E - F
D - E - F are commits in a branch and G is the merge commit. The merge commit's message, if they were doing things right, will contain some sort of reference about what they were working on. Maybe a link to an issue tracker. See my answer to Why should I delete feature branches when merged to master? for more detail.
Use the reflog
Git tends to keep old commits around for about two weeks before garbage collecting, so that gives you some buffer. You can note down their commit IDs somewhere, or use the reflog to recover them. Restoring them is as simple as git branch <name> <commit id>.
Use backups
Backups of your repository (you have backups, right?) give you another buffer.
Make a clone
Finally you can make a clone of the repository just before you delete the old branches and squirrel that away somewhere. If it turns out an old branch needs to be undeleted it can be pulled from that archive repo.
But likely nobody will think about those old branches again.
回答2:
You can use / and the branches will be displayed as grouped into folders (only displayed)
i.e. 2 branches named:dev/major/minor1dev/major/minor2
Will be displayed like that (supposed to be a tree):
dev
|---major
| |---minor1
| |---minor2
来源：https://stackoverflow.com/questions/52025714/group-git-branches