![]() To initialize an existing Git submodule: $ git submodule init To add a child repository to a parent repository: $ git submodule add To pull all changes in submodules: $ git submodule update -remote Create repositories with submodules $ git clone -recursive -jobs 8 Pull submodulesīefore running or building the parent repository, you have to make sure that the child dependencies are up to date. If there are nested submodules: $ git submodule update -init -recursive Download submodulesĭownloading submodules sequentially can be a tedious task, so clone and submodule update will support the -jobs or -j parameter.įor example, to download eight submodules at once, use: $ git submodule update -init -recursive -j 8 If you have already cloned a repository and want to load its submodules: $ git submodule update -init To clone a repository containing submodules: $ git clone -recursive ![]() You can use the following commands to use Git submodules in your repositories. These tools were created to support code-sharing development workflows on a more modular level, aspiring to bridge the gap between the Git repository's source-code management (SCM) and the sub-repos within it. What if you could put one project within another using a single command? What if you could just add the project as a child to any number of projects and push changes on the go, whenever you want to? Git provides solutions for this: Git submodules and Git subtrees. This would create redundancy and inconsistency in the parent repositories and make it difficult to update and maintain the child project. But, what if you want to use the same child project in many parent repositories? It wouldn't be feasible to copy the child project into every parent and have to make changes in all of them whenever you update it. The traditional method is just to copy the project to the parent repository. Suppose you want to use a single project as a child project inside a repository. eBook: An introduction to programming with Bash.Try for free: Red Hat Learning Subscription.However, when external updates are infrequent, then vendoring external projects is dead simple.Īssuming you're using a scripting language (Python, Ruby, etc.), then you'd put the other project in a "vendor/other project/" directory and use _relative import statements.Īssuming you're using a compiled project (Java, C\C++, etc.), then you have to build the other projects first and then build yours (w/ the appropriate linking). but, then you might as well spend time working on a proper build process. If you need to update the project frequently, then you'd want to to automate this. Instead, you could just download an archive of the other project and then extract it into your git repo. ![]() You could use git submodule or git subtree to do this, but as previously stated, they are neither easy nor convenient. "Vendor"-ing a project means you keep a copy of the other project within your project. ![]() More accurately, an atomic build process If you build commit "abc1234" today and then a build commit "abc1234" a year from now, then the two builds should be exactly the same. Just to reiterate, a build process is preferred.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |