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

Asked

Viewed 182 times

2

One of the main products of my company already has about 4 years of life. In the meantime many branches and tags have been created, and the repository has been migrated from SVN to GIT.

Because of this, the repository has a lot of old code and several branches that were created and never finished or deleted after merging with master.

We are currently looking to develop a number of new features, but not before clearing the repository and the code itself. Hence your experience: how to maintain a well-organized Git repository?

git

  • My point of view would be better to delete the old branches ... imagine something ... it happened cmg.... I created a branch but I had not seen that the name of this branch had already been created, I only realized when I went to merge .... imagine the headache that gave ... gets the tip .... wise same is the one who learns from the mistake of others.

2 answers

5

There is no single solution, what I recommend is to do a search in the various types of workflows and see what fits best with your company’s way of working. Regardless of which one is chosen, when one is chosen, adherence to it will imply cleaning up the mess.

In general, with git, I don’t see much point in having tags to delete later, usually the function of a tag is to have a fixed point of a version, lose this point doesn’t make much sense to me. Now with respect to branch, it will depend on the workflow, Feature branchs usually has a short life, but it is common to also have master, develop, and other branches for support of various versions, which are long-lived.

3


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. Are unfinished features, or 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 master only continue to exist if there is a need to roll-back functionality, as in a pre-production test environment, but I prefer to keep only tags by tagging these commits (something like v1.2.3pre1).

I believe that maintaining branches increases the complexity of understanding what’s in the repository, especially when a new member arrives on the team. Besides, I always end up spending some time reviewing what’s already abandoned

Browser other questions tagged git

You are not signed in. Login or sign up in order to post.