9

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!

simont
  • 68,704
  • 18
  • 117
  • 136
medconn
  • 243
  • 3
  • 8
  • I think you are missing something here, since `rebase` was designed *exactly* for your use case. It rewrites history because it's *supposed to*. If you're doing it right, it only rewrites history in a specific local branch, so no history in a central repo every gets rewritten. – Ben Lee Apr 22 '12 at 09:22
  • 1
    You could also do straight-up merge to make things simpler, but rebase is a better solution. – Ben Lee Apr 22 '12 at 09:23
  • Related: http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions – Ben Lee Apr 22 '12 at 09:30
  • Ben - thanks for the comments and the related post (which I'd read!), but that still leaves me with 2 questions: 1) Where can I find a simple comparison of the benefits of merge vs. rebase 2) Is the advice altered by the feature I forgot to mention in the original post, namely that I work with 2 other developers (+ a build machine!), and we therefore need to have BOTH versions available in a central repo. – medconn Apr 22 '12 at 10:00
  • 2
    @medconn 1) http://stackoverflow.com/questions/804115/git-rebase-vs-git-merge is a start. 2) Merge is the preferred route when a shared history is in play. – VonC Apr 22 '12 at 10:50
  • @BenLee disagree, rebase takes a branch out of some point and applies it on another point, it doesn't two branches in sync as the medconn requires. merge is certainly the solution here. – CharlesB Apr 22 '12 at 22:22
  • @CharlesB, I disagree. You *want* the commits from that branch moved. And it definitely *will* keep them in sync, since everything in the original branch will be in both branches. In a feature branch developed by one person (and "new version" can be considered a feature), I think a rebase is usually a better solution because you want all of the feature branch changes to be on top of the other branch for a cleaner history, rather than having them interspersed. In a feature branch developed by multiple people, merge is probably better just for logistical ease. – Ben Lee Apr 22 '12 at 23:50
  • @BenLee: what do you call `that branch` in OP case? legacy or master? rebase is good [in some cases](http://stackoverflow.com/q/2152841/11343), but not if both branches have diverged since some time, are quite different, and meant to be maintained independently, which is the OP case. Or else I'd be interested to see how it is applied in a detailed answer. – CharlesB Apr 23 '12 at 06:08

2 Answers2

5

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.

Simon Stender Boisen
  • 3,413
  • 20
  • 23
0

Have a look at Git flow - an approach to branching for these sorts of features with tooling to support it. Basically, for each new 'tweak', you do it on a fresh branch rooted at/before the common ancestor of the branches you're maintaining, and then you merge that to each of them.

Phil Miller
  • 36,389
  • 13
  • 67
  • 90