nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is it possible to delete a branch but have the option to revive it / un delete it later ?

Sam Lee_fszd3v

Ive got a project with lots of old branches for things we have tried but ultimately didn't make it into production.. they are beginning to be to many branches in this repo and id like to delete some of them.. the only issue is that i may at some point in the future want the code back, is there a way i can hide the branches or delete the branches but un hide or revive / un delete them later ?

Regards

Sam

Accepted answers

evzijst

No, there is no way to hide or archive branches in a way that they don't show up in Bitbucket of local clones, while still being able to revive them when necessary.

However, what some have done in cases like this, is make a fork of the repo that exists solely as a place to archive branch refs, while deleting branches that are no longer needed in the main repo. You could automate such approach by writing a script that keeps the fork in sync automatically, pulling in new branches from the main repo, but never pruning them when they disappear upstream.

All comments

evzijst

No, there is no way to hide or archive branches in a way that they don't show up in Bitbucket of local clones, while still being able to revive them when necessary.

Tim Crall1

If you delete an unmerged branch, it will still be possible to retrieve it for a little while, but eventually git's garbage collection will clean it up.

You could tag the commit and then delete the branch, but I'm not sure that would accomplish your goal. I suppose it would prevent the branch from being listed on the branch list screen. A tagged commit, because it is still reachable, will remain available for checkout even if it's not on a defined branch anymore.

evzijst

Yeah, relying on unreachable commits and the mercy of the garbage collector (which is entirely controlled by us, not by the user) doesn't seem like the thing Tim is looking for. As for trading branches for tags, I'm, not sure that would improve things. They still "pollute" the refs namespace and continue to gradually slow down operations both on Bitbucket as locally.

Tim Crall1

Agreed (and I think I more or less made both points in my answer). Forking is a good idea.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

bitbucket

bitbucket-cloud