What's the best way to manage parallel versions in Git?

Question

I have a well established software toolkit, but which often needs small tweaks (mainly to cope with compatibilty issues from 3rd party products). I now wish to produce a "new" version (improved API), which will be based on the original - this will diverge from the existing branch over time, but for a few years, I will need to keep the original "live" for existing customers who need it for compatibility. Of course, I also need to make sure that the "tweaks" get applied to the "new" version as well, since such issues would (in most cases!) also apply to the "new" version.

So - my ideal (simple) workflow would be:

1. When working on the "new" version - changes only apply to that version.
2. When working on the "old" version, all resulting changes would (as automatically as possible!) get applied to both versions once I am happy with them (when I commit, submit or whatever).

I realise that there will be need for occasional manual intervention, where merges are conflicting, but I would expect that to be rare, based on experience of manual changes in the past.

At the moment, I am looking to abandon VSS (yes - go on laugh at me for keeping it so long!), and I was hoping that Git would make this easy, but so far, there don't appear to any "simple" solutions, with the suggestions I've seen all being build around "rebase", which seems "wrong" to me, since rebase appears to do many other things such as rewriting history, when all I need would be a simple, genuine "move forward" based on the changes from the other branch.

• Am I missing something here?
• Is there an easier, properly defined way to do this?
• Would I be better off with a different source control system rather than Git?

All thoughts much appreciated!

Answer 1

You could just merge the changes from your old branch to the new version.

Let me elaborate on rebase: Unless your the only developer working on the codebase I wouldn't recommend that you use rebase for this particular problem. Remember rebase is recommended for use with private branches only since your rewriting history and thus invalidating any commits having a rebased commit as an ancestor.

If you rebase the old version-branch changes onto your new version then you will keep rewriting the history of the new version-branch every time you need to bring changes from the oldversion to the newversion. This means that any work that was done with a base in the new-version, say a feature-branch for a feature exclusive to the new version will be lost since the original commit no longer exists.