Menu
I'd like to incorporate an existing project (hosted on GitHub) as a part of my project (into a subdirectory) while maintaining the history and the ability to update that project. I've found that there can be about three approaches:
The (1) variant could be the preferable one at GitHub as they can probably share the sources. But logically my project is not a fork of the existing one. Rather the existing one is just a module. Also I'm not sure if moving the existing code into a subdirectory might not make problems. I would probably prefer the (2) variant as there is only one repo. (3) would require working with several repos but logically is the closest to my situation.
I have researched this quite a bit, but I'm not definitely sure. What would you recommend in this situation? Thank you in advance!
900
Git submodules may look powerful or cool upfront, but for all the reasons above it is a bad idea to share code using submodules, especially when the code changes frequently. It will be much worse when you have more and more developers working on the same repos.
About subtree merges We will: Make an empty repository called test that represents our project. Merge another repository into it as a subtree called Spoon-Knife . The test project will use that subproject as if it were part of the same repository. Fetch updates from Spoon-Knife into our test project.
git subtree lets you nest one repository inside another as a sub-directory. It is one of several ways Git projects can manage project dependencies. Management of a simple workflow is easy. Older version of Git are supported (even older than v1.
A git submodule is a record within a host git repository that points to a specific commit in another external repository. Submodules are very static and only track specific commits. Submodules do not track git refs or branches and are not automatically updated when the host repository is updated.
If the development lifecycle of the two projects (the one on GitHub, and yours) are different, then the submodule approach is better.
I.e: if you change your project without having systematically to change the other GitHub project, then you should consider the submodule approach.
However, to implement this, you would need a combination of (1) and (3):
It will allow you to refer one specific revision of the GitHub project, while allowing you to update that submodule and make specific push for it (as described in "true nature of submodules").
But once you have updated the submodule, don't forget to commit your project (which is the "parent project" for the submodule), in order to register the new revision of the submodule you are now referencing.
142
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
