Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
I wouldn't. Not unless you intend to keep developing on every branch independently! Presumably you're not doing that. In that case, I think it makes your intent clearer to just use a tag to mark t...
Answer
#1: Initial revision
I wouldn't. Not unless you intend to keep developing on every branch independently! Presumably you're not doing that. In that case, I think it makes your intent clearer to just use a tag to mark the version, then delete the branch. If you ever find that you do need to go back and make some changes that are specific to version 1.2.3.4, you can just create a branch again from that commit tagged 1.2.3.4. I can't think of a good reason myself to keep the extra branches around. Remember that branches are cheap in Git, it's not like Subversion where it has to copy or delete the entire tree! Tags and branches are essentially the same thing, they're both just ways of marking a specific commit to make it easier to get back to them later. I think that, in general, it makes it clearer to use tags to represent tree branches that you don't expect to have to do more work on, and actual branches for ones that you do. Besides which it means your `git branch` command won't be cluttered up with old versions you don't care about any more.