Git with two versions as branches

Question

I have a project with two separate versions. Each version is on another branch and they will never be merged together. Most of the code is equal but each branch has it unique parts. Now I need to get almost every commit into both branches.

Currently I use cherry picking for this: I switch to the other branch and pick all commits I need.

I don't like how I am doing this. It takes some time to pick every commit and your I might miss one.

How can I keep two mostly equal branches in sync while not losing the unique changes?

I have read several post on similar topics but none of them seem to apply for my situation:

I have also read this nice git branch guide but also I could not see a fitting solution here. The hotfix branch comes closest and I thought about creating one but I think the merge will overwrite stuff.

How do the branches differ, i.e. what is the nature of their unique parts? Would it be possible to have a single branch but use static configuration to select which parts or features to include? So far I'm not convinced that maintaining two branches is the best solution. — Magnus Bäck, Dec 17 '13 at 17:20
possible duplicate of [git best pratices for developping a code for two different devices](http://stackoverflow.com/questions/19936776/git-best-pratices-for-developping-a-code-for-two-different-devices) — Robin Green, Dec 17 '13 at 18:50
I would suggest a third branch - called `common` or something - that contains all the parts that are always the same in both development lines, then make the other two branches be only about the pieces are different. Then you can periodically merge the common branch into each (or rebase if you prefer) of the separate lines... — twalberg, Dec 17 '13 at 19:00

mockinterface · Accepted Answer · 2013-12-18T12:28:34.833

A common practice is to create a topic branch for your incremental changes based on the branch that's most suitable for developing the particular topic / feature / bugfix sought. Then the topic branch is merged into both your branches and discarded. The merge will not overwrite your history, on the contrary, it will all be there, fully preserved.

                    /-- * -- * -- * -- A
*-- old history -- * 
                    \-- * -- * -- * -- * -- B

As you've described, the assumption is that A and B will never merge in the future. When you need to add a feature you pick either A or B, whichever is more natural for that particular case, and develop there:

                                   /-- * -- * -- * -- C
                    /-- * -- * -- * -- A
*-- old history -- * 
                    \-- * -- * -- * -- * -- B

Then merge C to both A and B and discard it:

                                   /-- * -- * -- * -- C --\
                    /-- * -- * -- * ----------------------*[merge] -- A
*-- old history -- * 
                    \-- * -- * -- * -- ..               --*[merge] -- B

(I missed my chance to take ASCII art lessons from Henri Matisse.)

Here's something very straightforward:

$ git checkout A
$ git branch C
$ git checkout C
$ develop.sh 24h commit commit commit
$ git checkout A
$ git merge C
$ git checkout B
$ git merge C
$ git branch --delete C

You should be able to see much nicer ASCII art by now running: $ git log --oneline --graph You'll see that merge didn't destroy any of your history. Of course you don't need --graph for this, it is also visible with just plain git log.

Git with two versions as branches

1 Answers1