Search code examples
gitarchitectureopen-sourceproject

How do you synchronize a fork with parent project if it is big?


This is a theoretical question, I just want to make it clear for myself.

Let's say you get a task from your customer to make something big. Let it be a custom browser with bells and whistles or a custom Android ROM with a lot of customer services.

After some research you find out that you can use some opensource project as a basement but the customer's wishlist requires you to make lots of changes that include adding or deleting a lot of code, removing some modules from the project, changing the architecture of some components, rewriting something deep in the heart of the project etc.

Now let's say you have successfully implemented everything, the customer gave you the money and made an offer to sync the code base with current parent project's state for some extra payment.

And now the question: what is the best way to sync the code base with the parent if:

  1. You are using some version controlling system (i'm personally interested in git but if there're solutions for other ones, I'd like to know)
  2. Your development was lasting for some years while the parent project didn't stand still and you didn't fetch changes from it because there wasn't a line about this in the contract.
  3. You couldn't know anything about supporting the project in the future
  4. You made so many changes that simple git merge would produce a lot of conflicts and resolving them is similar to rewriting everything from scratch
  5. You're not willing to spend the whole life transferring the changes.

If there's no way for quick merging, what is the best approach in terms of architecture to avoid these situations?


Solution

  • Git is actually probably your best bet. It has lots of great merge tools. If the original project is a git fork, then you are good, create a new branch from the current code-base, then either merge your changes in, or do a rebase. It will be slow, painful, and will probably need to go one-commit-at-a-time. Hopefully you wrote lots of unit tests to find your failures. Learn git-bisect, it will save your life (determining when things broke in your commit stream).

    In response to your comment, big projects that fork other big projects:

    (1) try REALLY HARD to keep their changes modularized and out of the core functions of the parent application

    (2) go through this same process of merging or rebasing on a regular basis.

    Regardless, from a logical standpoint, you will have to resolve all the conflicts, and it will likely be expensive and time-consuming.