Should old tags and branches be deleted from the remote repository?

I prefer to keep my repositories as clean as possible.

In this way, I try to apply the following rules:

• Branches that have code that will not be used are deleted. These are unfinished features, whether they test something that did not work. I believe there are better places than the repository to document this kind of "failure."

• Branches that have already been merged into the master will only continue to exist if roll-back functionality is required, such as a test in a preproduction environment, however I prefer to keep only tags by marking these commits (something like v1. 2.3pre1).

I believe that keeping branches with the complexity of understanding what's in the repository increases, especially when a new member arrives on the team. In addition, I always end up wasting some time reviewing what is already abandoned

There is no single solution, so I recommend you take a look at in the various workflows a> and see what fits best for the way your company works. Regardless of which one is chosen, when one is chosen, adherence to it will entail cleaning up the mess.

• Git Workflows by Atlassian
• GitHub Flow
• Gitflow, A successful Git branching model
• GitLab Flow

In general, with git, I do not see much sense in having tags to be deleted later, usually the function of a tag is to have a fixed point of a version , missing this point does not make much sense to me. Now with regards to branch, this will depend on the workflow, usually has short lives, feature branches , but it is also common to have master, develop, and other branches to support multiple versions, which are long-lived.