I do this for my vim plugins for example. When you have a component that isn't updated very often and you want to track it as a vendor dependency. When a component or subproject is changing too fast or upcoming changes will break the API, you can lock the code to a specific commit for your own safety. There are at least three scenarios where submodules are a fair choice: Possible Workflowsīy remembering this core concept and reflecting on it, you can understand that submodule support some workflows well and less optimally others. Until you update the parent project, nothing changes. You have one remote repository, and you point to a single commit. If you have a bunch of forks of a module, git submodules don't care. If you add commits to a submodule, the parent project won't know. You are tracking specific commits with git submodules - not branches, not references, a single commit. When you make changes and commit in that subdirectory, the superproject notices that the HEAD there has changed and records the exact commit you’re currently working off of that way, when others clone this project, they can re-create the environment exactly. As very clearly expressed in the Pro Git chapter mentioned earlier: They are never automatically updated when the repository specified by the submodule is updated, only when the parent project itself is updated. Submodules are tracked by the exact commit specified in the parent project, not a branch, a ref, or any other symbolic reference.
0 Comments
Leave a Reply. |