Split a git repository to work on two projects at the same time

Question

I am developing a framework to use on my projects; however, the developing of a framework can go so far without context: i.e. I need to start using it in real-life projects and see specifically what I need to add, fix, or adjust (maybe things that worked on a testing environment don't work for real-life situation, or some things don't make sense, or I want to add features).

First of all, since Framework is obviously a work in progress, I need to be sure that it is kept updated within Real-life project as a different part of it, so I can go back to Framework, edit it, commit, go back to Real-life project update Framework within, go on working with the project.

Second, I would actually like a way to achieve this without doing the project switching. What I mean is that I would like to be able to edit Framework within Real-life project and push those commits to the Framework repository.

Now, I know that the tools to achieve this are most likely git submodule and git subtree, but both of them are pretty confusing. Submodule, especially, seems it is more oriented towards a read-only approach (e.g. keep your libraries always updated): this would satisfy my first requirement, but not the second.

Any pointers on how to achieve this with Git and how the workflow would look like?

Answer 1

Any of the two approaches would serve you.

Each one can allow what you need, to edit the project in place and to push that specific content to a separate repositories.

Both approaches would also incur in an amount of overhead in order to keep both projects running.

About the two points you mention:

• With Submodules you would have a repository inside a folder of other repository. The outer one (Real-Life) keeps saved in a file the location of your submodule (Framework) repository, and the current commit being used. When you want to edit Framework you just go to the sub-folder where it is stored, and inside there it should behave as if you where in a completely separate git repository with its own remote and history. After modifying Framework you return back to Real-Life and update the submodule references. The process would look usually like this:

  Edit files in Framework
  Move to Framework subfolder
  Stage, commit, and push changes to Framework repository
  Go back to Real-Life folder
  Update Real-Life submodule reference
  

• With Subtrees you work with Real-Life and Framework in the same repository, still keeping Framework code under a specific sub-folder. When you change content in Framework you still commit those Real-Life repository as if was a single project. What the subtree tools allow is that you can isolate the changes that you have in the Framework folder and create from these a set of commits that exists separate from Real-Life, this commits will contain Framework-only changes and can be pushed the the Framework repository. The process would look like this:

  Edit files in Framework
  Stage, commit, and push to Real-Life repository
  Create Framework commits using subtree tools
  Push Framework specific commits to Framework repository
  

If you are still unsure of the trade backs that exist between these two I would suggest that you go with using submodules. You will find more documentation, use cases, and is generally less complex. It has some short-comings but by being familiar with submodules first you could gauge what subtrees offer. More info about submodules.