I am working on a project that will have multiple versions that I’d like to track. However, these branches won’t ever be merged, I want to keep them almost as separate projects.
For example, let’s say there’s 3 versions:
A
B
C
These won’t ever be merged, and will have their own branches that are separate from each other.
The reason I don’t want to just use branches, is because I would like a bit more separation between the versions, so it can be as organized as possible.
And I would like to keep these versions in the same repository.
Kind of like this:
A_main ------------>
↘
A_branch ----->
#######################
B_main ------------>
↘
B_branch ----->
#######################
C_main ------------>
↘
C_branch ----->
I’m thinking about using git worktree for this. Are there other ways to accomplish this goal?
2
The following are ways of doing what you want in the same repo, each with their pros and cons.
- use “perma” branches. Just branch your version at the right point and keep it around forever. You can use a pseudo-folder structure for organization. I do this when I am documenting something related to code, but don’t want the link to the code to break (e.g.
perma/docs/3.0.0). For you, it might beversions/v2.3.4for example. But, these branches, of course, still tie back to whatever you’ve branched from. - use git-worktree as this user does. This is probably the most complex mechanism but seems to match your description of what you want to do more closely.
If you decide leaving the confines of a single repo is OK, you can
- fork the repo. This creates a new repo but allows you to know where the fork came from for tracking purposes.
- manually create a new repo and copy the code there, optionally with or without history.
The perma branches thing kind of looks like a modified gitflow, but where the release/hotfix branches don’t get merged back. Git is flexible to be sure so any of these approaches might be suitable for you.