Archiving Git Branches as Tags
Key topics
The debate around archiving Git branches as tags has sparked a lively discussion, with some arguing it's a useful practice for preserving abandoned or unmerged feature branches. However, others pointed out that tags aren't immutable, as some Git UIs make it harder to update them, but they can still be changed - a point echoed by those who've had to deal with coworkers overwriting existing tags. Key differences between branches and tags were highlighted, including Git's handling of reflogs and the expectation that branches will change, while tags remain static. The discussion also touched on the practicality of archiving branches, with some users sharing their workflows and questioning the need to revisit archived tags after a certain period.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3d
Peak period
29
72-84h
Avg / period
11.8
Based on 47 loaded comments
Key moments
- 01Story posted
Dec 22, 2025 at 1:52 PM EST
11 days ago
Step 01 - 02First comment
Dec 25, 2025 at 3:17 PM EST
3d after posting
Step 02 - 03Peak activity
29 comments in 72-84h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 27, 2025 at 8:07 AM EST
6d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
It's not guaranteed not to change. The UI just makes it harder to update.
would clobber existing tag
Really wish my coworkers would leave old tags as they were heh.
I'm sure that would cause problems for some, but transitive labels already exist in Git: branches.
Of course, the repository owner has unlimited privilege here, hence the last part of my prior comment.
Packed refs are a little more complicated but all of the storage formats in git are trivial to manually edit or write a tool to handle, in extremis.
https://docs.github.com/en/repositories/configuring-branches...
https://docs.gitlab.com/user/project/protected_tags/
https://forgejo.org/docs/latest/user/protection/#protected-t...
One is refs/heads/<name> and the other is refs/tags/<name>
Branches are expected to change. When a commit is authored, HEAD (the current branch) updates to that commit.
Tags are expected not to change (though they can).
Sometimes I work on a feature, and it doesn’t quite work out for some reason or another. The branch will probably never get merged, but it’s still useful for reference later when I want to see what didn’t work when taking a second attempt.
Currently, those abandoned branches have been polluting my branch list. In the past I have cloned the repo a second time just to archive them.
We also keep merged branches around. This has never happened, but if we needed to bisect at the merged-branch level, we could do that.
I know squash-merge isn't everyone's cup of tea, but I find it to be simpler and clearer for the 99+% case, and only slightly less convenient for the remainder.
Now the work is visible in history, branch can be deleted, and anyone in the future can search the ticket number or whatever if your commit messages are useful.
Dunno if it's worth polluting history, just thinking out loud.
Any branch older than 6 months is a strong candidate for deletion.
It just moves trash from branch list to tag list.
If you don't anticipate working on a branch but you want to preserve the code you leave it but it starts to clutter that prominent "active" space in most git tools.
This allows you to preserve the code (if you ever want to look at it again) while also de-cluttering the prominent "branches" view.
`git push —all backup` will record all of your refs and tags
If you are archiving branches in your own rep, prefix with `ar/` so you can grep -v to conceal them.
See also `git notes` to record metadata an against a commit without changing the commit
I dislike the official git completion script because it’s so slow when working with large repos. On macOS - because of vagaries of the way its file system works - with large repos it’s effectively unusable. Hint to completion script writers: if your “smart” completion ever takes seconds, it’s worse than useless and far worse than “dumb” filename completion.