I am part of a team that has recently moved from an SVN repository to a Git repository, and have started using GitFlow.
As I understand it, this means that in a perfect world, the minimum number of Git branches can be as few as two: master and develop. In practice, there'll be more, accounting for release and topic branches, but the fundamental goal is to streamline the process and always be merging branches back towards Develop, and thus Master. For all work going forwards, this is fine.
My question comes from our previous SVN way of doing things. In addition to the "Trunk" (now "Develop") branch, we had a bunch of one-of customer branches for particular releases. These were all converted as part of the git conversion process, so that our git repo looks like this:
The hotfix/, release/, and topic/* branches I have a good sense of what to do with. But what about all the other, historical branches? Our previous SVN conventions meant that anything we made in a customer release branch was also done in trunk, so none of these branches have unique code not already in develop, so there's no need to ever merge them back into develop at all.
Can these branches be tagged (at the current head), and then deleted? (Perhaps I'm misunderstanding the point / use of tags and/or GitFlow itself) Or is our repository doomed to always have these legacy branches, as long as we're interested in maintaining the history?