How do I fork multiple projects into one repository with git?

I have a 3 projects I’d like to fork. They’re all related to each other – changing one will likely require a change to another. Because they’re all related, I’d like to create 1 repository for the forks, while maintaining the ability to pull down updates from each original.

How would I setup my git repository?

  • How do I turn a git clone into a fork and then push to heroku from the fork?
  • What's the purpose of forking a git repo?
  • What is the proper practice for managing local, remote, and upstream repos on GitHub?
  • How to update GitHub forked repository using TortoiseGIT?
  • git merge and got this error “does not point to a commit”
  • Updating forked GitHub repo to match original's latest code and commits
  • These are preliminary thoughts so I wouldn’t be surprised if this is crazy/stupid. Is it?

  • Git Logs and Control per user
  • ClearCase to Git migration
  • How to push a new branch non-existing on the remote server without --set-upstream?
  • Git mergetool using Android Studio (IntelliJ)
  • How to create a repository with ssh:// access on a server
  • How to Sync the Same Exact EXISTING Project on Machine2 that was Pushed To a Git Repository from Machine1?
  • 4 Solutions collect form web for “How do I fork multiple projects into one repository with git?”

    You can always use “git remote add <name> <url>” to add more repositories as source.

    You may be interested in git-submodule functionality. Quote from here:

    Git’s submodule support allows a
    repository to contain, as a
    subdirectory, a checkout of an
    external project. Submodules maintain
    their own identity; the submodule
    support just stores the submodule
    repository location and commit ID, so
    other developers who clone the
    containing project (“superproject”)
    can easily clone all the submodules at
    the same revision. Partial checkouts
    of the superproject are possible: you
    can tell Git to clone none, some or
    all of the submodules.

    There’s one possibility I’ve never tried “for real” but that might work well.

    Let’s say you have three projects creatively named Proj1, Proj2 and (guess it) Proj3. Let’s also say that all or some of them depend on external libraries, for example one called Lib1.dll and another called SuperLib.dll.

    First, for the folder structure, I’d do something like:


    Then you would create one repository on each of the ProjX folders:

    cd \MyCode\Proj1
    git init
    cd \MyCode\Proj2
    git init
    cd \MyCode\Proj3
    git init

    Then you would create a repository for the whole thing:

    cd \MyCode
    git init

    The contents of this repository, for git, would be the Libs folder and its contents, the build_all.bat build script, and 3 subprojects.

    So once you change your source code, let’s say Proj1\Main.cs, the whole thing wouldn’t see the modification. You would have to git commit on Proj1, and then you would go to the whole thing and then git commit it (now git will be able to see that Proj1 has been modified).

    Using this method, the history of the whole thing would simply state when the ProjX were modified, but it would not directly keep track of individual files. Howver, as expected, the repository on ProjX would keep track of every file, as usual.

    If you give it a try on a “real project”, let me know the results!

    Good luck!

    I think I should be using the subtree merge strategy. I’ll have to actually try it out and see if it works well. I’ll mark this answer as accepted if this turns out to be a good approach.

    In the mean time, I’m still open for suggestions.

    Git Baby is a git and github fan, let's start git clone.