I have a C codebase which supports a number of build personalities, for a given board architecture. It’s mostly in maintenance mode. We don’t do new active development on it.
We have a new board for a generation 2 of the product. Generation 2 will replace generation 1 (we aren’t making any more Gen 1 boards). Generation 2 will require a good chunk of the code to be rewritten completely. I’d say 50% of it. OTOH, there is some code that will just stay the same. Making the build modular to support both types isn’t worth it to us. So we’re essentially going to permanently fork the project into two.
I’m soliciting input on whether to just
- Make a new git repository, copy the code from the old into it and take off and see where the future takes us.
- Keep the same repository, but just add more branches.
We currently use a scheme in our repository of having a master branch for production releases, a testing branch where we accumulate “blessed” work, and individual branches for different units of work we do.
The Pros/Cons as I see them are:
- Two Repositories
- Pros: Branches stay simple. Forced to have a repository for each loaded if I need to compare
- Cons: Can’t cherry pick between the two (we rarely do this though)
- One Repository, Different Branches
- Pros: Code all stays in same branch, maybe able to leverage some “cross branch” features of git
- Cons: Have to annotate the
masterandtestingbranches for the two different things to disambiguate them
Which should we do, and why?
1
Because git is so flexible, you could probably do fine either way, and which one is the more correct answer depends entirely on what your day-to-day workflow is like, so I’ll give the answer for the workflow I’m used to (which I think is one of the “normal” ones).
Most of the time I’m typing a git command or figuring out what git command to type, one of the big assumptions I’m always making is: “There is only one branch with ‘real’ code (code that rolls out to production and makes the business money), and it is master; all other code is not ‘real’ until its branch passes code review and is merged into master.” Although git in no way requires you to make this assumption, I think that’s how a lot of real-world development works.
The single repository option essentially means you have a repo with “two master branches”. Unless you plan to be developing and delivering two different products in parallel that share a lot of code (which in this case you aren’t), I think that’s a little bit unintuitive and error-prone compared to giving each product a separate repo. Personally, I know I’d always be slightly worried about merging something into “the wrong master branch” by accident if my team did this.
Also, as amon said, git does not stop you from moving code between repos. A few git fetch and git cherry-pick commands should be all you need to apply “old” commits to “new” code branches. It’s not much harder than moving things around within a single repo. It’ll feel different, but it probably should feel different.