Bitbucket create submodule12/30/2023 Git log # still commits from Project Slingshot Git log # log shows commits from Project Slingshot On the command-line, Git commands issued from slingshot (or any of the other folders, rubber-band and y-shaped-stick) will operate on the “parent repository”, slingshot, but commands you issue from the rock folder will operate on just the rock repository: cd ~/projects/slingshot You can interact with all the content from rock as if it were a folder inside slingshot (because it is). That’s it! You’ve embedded the rock repository inside the slingshot repository. On GitHub, the rock folder icon will have a little indicator showing that it is a submodule:Īnd clicking on the rock folder will take you over to the rock repository. If everything looks good, you can commit this change and you’ll have a rock folder in the slingshot repository with all the content from the rock repository. Newer versions of Git will do this automatically, but older versions will require you to explicitly tell Git to download the contents of rock: git submodule update -init -recursive In the slingshot repository: git submodule add rockĪt this point, you’ll have a rock folder inside slingshot, but if you were to peek inside that folder, depending on your version of Git, you might see … nothing. You can add rock as a submodule of slingshot. You’ve got code for y-shaped stick and a rubber-band.įlickr photo shared by under a Creative Commons ( BY ) licenseĪt the same time, in another repository, you’ve got another project called Rock-it’s just a generic rock library, but you think it’d be perfect for Slingshot. Let’s say you’re working on a project called Slingshot. Submodules allow you to include or embed one or more repositories as a sub-folder inside another repository.įor many projects, submodules aren’t the best answer (more on this below), and even at their best, working with submodules can be tricky, but let’s start by looking at a straight-forward example. Git provides submodules to help with this. This is probably preferable to the above solution, since it saves the user the trouble of moving between different pull requests and keeps the review in one place.Eventually, any interesting software project will come to depend on another project, library, or framework. Instead of having separate pull requests in the child repos, there is just one pull request in the parent repo, covering all the changes. The GUI could be modelled on the Jira issue/subtask feature.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |