5

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.

Maor Refaeli
  • 2,417
  • 2
  • 19
  • 33
Daarwin
  • 2,896
  • 7
  • 39
  • 69
  • What do you mean easier to spot? What are you looking at? `gitk --all`? `git branch -all`? – kabanus Aug 26 '18 at 11:20
  • I guess i dont know the answer cause i dontknow all the options. I always use git branc -r. – Daarwin Aug 26 '18 at 11:21
  • That will show all remote-tracking branches. You need to define a goal here to make this a clear question - `git branch --list ` will give all branches matching pattern, just typing `git branch` will show the current branch. What do you want to actually happen? Sounds like you could delete most of these branches, leaving a tag? – kabanus Aug 26 '18 at 11:25
  • I want to be able to distinguish between brances that i work with and the other branches that dont really make sense atm but still cant be deleted. – Daarwin Aug 26 '18 at 11:26
  • will it be better to figure out what branch don't contain "unmerged yet" commits so they could be safely deleted? – skyboyer Aug 26 '18 at 11:57

2 Answers2

15

You can use / and the branches will be displayed as grouped into folders (only displayed)

e.g. 2 branches named:
dev/major/minor1
dev/major/minor2

Will be displayed like that (supposed to be a tree):

dev
|---major
|   |---minor1
|   |---minor2
Maor Refaeli
  • 2,417
  • 2
  • 19
  • 33
9

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.

Schwern
  • 153,029
  • 25
  • 195
  • 336
  • 1
    minor: s/topography/topology/ (though one could argue that "topography" is fine and accurate since graph topology arose through mapping! :-) ). – torek Aug 26 '18 at 18:03
  • @torek Thanks. I'll just say "the connections between the commits". – Schwern Aug 26 '18 at 18:08
  • When I clean up a repo to get rid of old branches and replace them with tags, I use a few standard prefixes in all caps, mostly `END_`, and then the original name of the branch. And instead of a lightweight tag, I make it an annotated one and explain why it was ended, or what it was for (if I can tell or someone knows). That annotation might be as simple as "cleaning up repo, this is an old branch" that I just copy and paste to every `END_xxx` tag... I usually just delete the merged branches, but if the history is messy I might tag it with a `MERGED_xxx` tag. – LightCC Feb 24 '22 at 01:08