Merge two git branches which had a common ancestor but are (almost) not the same project

Question

Related but not quite what I am looking for merge-two-branches-what-direction.

Situation:

I have inherited an interesting problem. So we have a rails application that houses the code for a number of websites. Before I came to work here they branched the master branch to develop a new website. That's great but it was never merged back into master, and changes from master were not merged into the branch to keep it up to date.

Now master has 2 new websites and almost a third done while this branch has the one it was branched for and a new one that was similar enough to it that development was made simpler by doing it in that branch (like min saving of 100 hours).

Also they use the same database-structure and authentication systems which is really important for keeping track of our customers. Which is why I would like to merge them so I don't have to make the same changes to each code base when we change something in the database ect...

Problem:

My problem is that Now I don't know what to do with this branch. I want work being done out of the master branch with the occasional break off for a new feature that's rolled back in, but that's not whats happened. Its almost like we have 2 master branchs now because the code bases have grown so far apart.

I have tried merging the master into the other branch but that resulted in chaos, which we can't afford since there is development going on in both branches. So then I created a local branch and tried to merge the two into it. But after struggling with it for a couple days now and seemingly getting all the conflicts merged, only to have it fail my unit-tests and normal testing.

Plea for help:(question)

I am starting to think its impossible to merge the two since they are almost separate projects at this point (merging them involved adding or changing something like 430 files)

In short I guess my question is this: What do I do with the branches now?

(This is the first time as a developer that I have been in-charge of the source control and overall project management. So really at a loss here.)

p.s. sorry for the wall of text,

Wall of text indeed, may I suggest using some section headers to make it a little easier to read? :D — Kzqai, Aug 28 '12 at 15:12
thanks for the suggestion moved somethings around added headers hopefully its easier to read now. — Ryan, Aug 28 '12 at 15:20

score 4 · Accepted Answer · answered Aug 28 '12 at 15:32

First of all, forks are ok! If you have two branches that have diverged, maybe it's worth it to consider them separately. I would only really try to merge them back in if there are great core code improvements in each that it would be good to share with each-other. Otherwise, forks are often useful to just go with.

That being said, let's assume you are going to endeavor to merge them.

First of all, I would decide which branch is actually your master branch. Sure, one is called master, but for the purposes of this merge, you should decide which branch is more shared and would affect more people if the history would change. Usually this is indeed the master branch, but if no-one else has a copy of master, you can pick whichever seems like it would be easier.

Ok, so now that you have a "master" branch, you should be endeavoring not to disturb the history of that master branch. We'll call the other branch tf (for totally_forked). Whether that comes from a large merge commit getting added to the top of the branch, or a rebase that will preserve most of the commits from tf. Here is what I would do first:

Create a full backup of the repository! <-- Always do this when in doubt.

Trial Merge

git checkout tf;
git branch tf_merging;
git checkout tf_merging;

git merge master; Examine the extent of the conflicts. See whether these are conflicts on duplicate fixes (in which case commits can be eliminated) or on parallel fixes // If you don't think that you can use the merge, just abandon this branch:

git checkout tf;

Interactive Rebase

git checkout tf;
git branch tf_rebase;

git rebase -i master; // Interactive rebase. Using your list from the merge attempt, try to eliminate duplicate commits to prevent. Also see if rearranging tf's commits gives a better merging candidate.
// If too many conflicts occur:

git rebase --abort

// Only try to go through a few cycles of git rebase --continue after the rebase begins, perhaps 7-10 at most, otherwise you could probably deal with conflicts excessively and end up with a broken mess at the end anyway.

The Final Solution

If you can't achieve the solution you want through git, there is an alternative, which is to pick and choose features that you specifically want to preserve from the non-master branch tf, and discard non-essentials. For example, if there's a library added in tf that doesn't exist in master, set that and other useful features aside to add in a clear commit off of master, to create a branch that is like tf, and has the same functionality, but is actually a re-implementation of the most useful/core feature changes with many non-essential commits skipped. Essentially, you kill tf and reimplement the best parts of it on top of a branch off of your core master, to allow shared development to start again.

score 1 · Answer 2 · answered Aug 28 '12 at 15:19

Ryan, you can create a new project where you gradually copy parts of the old project enabling your team to work on the two different branches in the meantime. The good part is that you have to migrate working code so you will not have the same pain as implementing 430 files from scratch. Start with the very base of your application and always migrate a small number of files, gradually reaching the merge effect. Also, you should pay attention to changes on the files already merged in the two branches. Good luck.