"forking" own project in git

Question

I currently have the following situation: I need to maintain a repository which contains multiple versions of essentially the same project as subdirectories. Lets call the dev/most important project "main" and the other projects "sub_1",...,"sub_n".

The versions are distinct, but largely the same: think of examples like an Android project for Android 2.1 instead of the 2.2+ your develop for, a modified CSS Stylesheet for IE6, a custom build for a large client, those sort of things. Each version usually has a subset of the "main" files with minor modifications.

Currently I'm using the following method to change the files in the project:

• For 0≤i≤n
• Look at the files sub_i uses
• Overwrite the files sub_i uses with the correct ones from main
• Diff the changes, ignore changes which are part of main but re-apply the "patches" sub_i did to the files

Obviously this process is tedious and error-prone. I have searched for a few ways to do this and essentially have the following:

• What I'm doing now. Less than ideal for described reasons
• Branching. This does look the most promising but I do not know how I would branch only a part of the repository. (if I do a full branch I still don't have a way of merging the files efficiently)
• Submodules. These might work but from what I understand they're only to be used for fully external projects and not for copies of the same repository

Does anyone know the correct way to do this?

Note that maintaining the /main and /sub_i (git repository as root) directory structure is desirable, since changing that could break a lot of things (not the software itself but mainly the build tools etc.)

Answer 1

Subrepo approach

When I understand you right, your repo looks like this:

root
+ main
+ sub_1
+ sub_2
+ sub_N

Where main acts like some sort of library or framework, and sub_1..sub_N are more or less different branches of the same software. One solution would be to place main as submodule of sub_1..sub_N, so in the end the tree would look like

root
+ main (=submodule)
+ source of sub_X, = on branch sub_X

Here all your sub_1..sub_N folders are different branches of a single repo, and your main/ folder is a different repo. This is a possible way, if all sub_X folders are derived form a common base, and it is easy to develop on this common base and do merges from the common base to the sub_X branches to distribute these changes. But there is a big drawback of this scenario: it needs that everyone who develops with this structure knows exactly what he does, since development on a sub_X branch is not easy to distribute to the common base or other sub_Y branches via merge, since a merge operation would not only transfer the new changes to the other branches, but also the changes which makes the sub_X branch different from base or sub_Y. So generally I would advise against this approach.

Specialization

Another approach would be to isolate the sub_X changes, and create a base version which consists all stuff which is same in sub_1..sub_N, so that the sub_X folders only consists of the specialized stuff. It depends on your development/deployment strategy if this is a usable way.

Real branches

Since you wrote that the sub_X folders are copies of main, it looks that main already acts as the common base for all sub_X folders. If this is the case, you can change the different folders into branches. You can achieve this by

1. creating a branch for the main folder (git checkout -b main)
2. remove all sub_X stuff
3. move all main/* stuff into /

4. commit

5. for each sub_X folder

6. create a sub_x branch based on main (git checkout -b sub_x main)
7. remove all but the sub_X folder
8. move all sub_x stuff into /
9. commit

Afterwards you have a version graph like this:

 -o-o-(past history) - main -- sub_1
     /                      \--sub_2
 -o--                       \--sub_N

Then you can develop new features on the main branch, and merge these features to the sub_X branches. The main thing with a multiple branch setup is, that you always need to decide the correct starting point for a new development, since a merge operation will transfer unwanted changes between branches, if you did not used the correct start point. The correct starting point is the revision, which is the ancestor of all branches, where the new change should go. If you want to develop a bugfix for something which affects all sub_X branches, you need to develop this bugfix in main, since main is the common ancestor of all sub_X branches. OTOH if you have something very special for sub_23, it is correct to develop the stuff on the sub_23 branch.