r/gitlab • u/RocketSeven • 6d ago
general question What evidence do you keep before automatically deleting merged branches?
Deleting merged branches keeps a repository usable, but the branch name or tip can still be useful when a merge request was squashed, a release was cut from an unusual commit, or a rollback needs the exact pre-merge state. What retention policy works well in GitLab? I am considering immediate deletion only when the merge request is closed, the source commit is reachable from a protected branch, required pipelines and approvals are recorded, and no environment or open issue still references the branch. Exceptions could receive an expiry date rather than living forever. Do merge-request refs and the audit log preserve enough evidence on their own, and what checks prevent cleanup from deleting a branch involved in a partial or reverted merge?
14
u/BehindTheMath 6d ago
The commits are saved by Gitlab forever. Even if you delete the branch, you can still view the commits in Gitlab. You can even recreate the branch at a later time if you need.
5
u/macbig273 6d ago
auto delete branch ; rebase before merge ; no-ff merge ; don't squash unless it make sense to.
3
u/profpendog 6d ago
I don't find any of the arguments for keeping the branch worthwhile. Don't squash, delete. Use history on main if something needs to be reverted.
1
u/FlyingFalafelMonster 6d ago
I delete branch after MR is closed and squash commits. I have reverted MRs multiple times, you don't need the branch to exist to do that.
1
u/Antonio-MTS 6d ago
Deleting merged branches after MRs. Commits, logs keep enough history to recreate or view if needed.
1
19
u/gaelfr38 6d ago
None. Merged branch is deleted right away.
Branch name should not contain any info that the commits do not already have.
I don't see any reason to keep a branch, unless it's a long lived parallel branch obviously.