5

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:

sourcetree snapshot

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?

Improve this question

1 Answer 1

Reset to default
6

Whether to keep the branches around or to convert them to tags is largely a matter of personal preference.

Git has two kinds of tags: lightweight tags that are just a reference to a commit, and annotated tags. Annotated tags are git objects that can include a message and/or signature, like a commit.

Branches are basically the same as lightweight tags, except that they are moved automatically when you add a commit to a branch. (You can manually move branch references with git-reset.)

If you won't ever add commits to these historical branches, then converting them to tags would be idiomatic:

  • ensure that the branch is merged into master.
  • create a new tag
  • delete the old branch

Tag names and branch names live in different namespaces (refs/tags and refs/heads) so you can keep the existing names for the tag.

Improve this answer
3
  • To clarify, when you say "merged into master", the goal of that is just to aggregate all the code changes, correct? I think I'm slightly confused since for topic branches, merging also means deleting the topic branch post-merge.
    – Sable Dreamer
    Aug 8, 2018 at 20:04
  • @SableDreamer Merging a branch b into master in the most general sense just means that all commits of b are now part of the history of master. Here such a merge is not strictly necessary, but it makes it more obvious that all work that was done for these releases is included on the master branch. This kind of merge is for us humans, not for git. We can use the git merge -s ours obsolete merge strategy to ignore any changes from the obsolete branch during a merge.
    – amon
    Aug 8, 2018 at 20:31
  • 3
    I would additionally point out that branches can be created from tags at any point in the future, should an unforeseen need arise, so you don't have to be 100% sure you won't ever need to add commits.
    – Karl Bielefeldt
    Aug 9, 2018 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.