Why submodules

Pain points

We may encounter the following problem when developing projects: using another project in your project, perhaps a library developed by a third party or one that you developed independently and used in multiple parent projects. To put it simply, it is A module developed by A student, which is used by B and C… Students call (use) together, may form the following relationship.

A common problem arises in this scenario: you want to treat two projects separately but need to use the other in one.

The solution

Git already has a solution for this problem — submodules.

  • Submodules allow you to use one Git repository as a subdirectory of another Git repository. It allows you to clone another repository into your own project while keeping the commit independent.
  • Submodule keywords:git submodule

How to use submodules

Suppose I don’t currently have two repositories, Module (target repository) and SubModule (submodule repository).

Add submodules to an existing repository

git submodule add https://gitee.com/Hancoson/submodule.git submodule

  • You now have a subModule project in a subdirectory of project Module. If you run Git status immediately after adding a submodule, you’ll see two items:

    On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
    new file:   .gitmodules
    new file:   submodule

  • Look at the.gitmodules file

    [submodule "submodule"]
  path = submodule
  url = https://gitee.com/Hancoson/submodule.git

If you have multiple submodules, there will be multiple entries in this file. It is important to note that this file is under version control just like any other file, just like your.gitignore file. It can be pushed and pulled just like any other file in the project. This is how other clones of the project learn about the origin of the submodule project.

  • Commit the added submodule to the remote repository of the existing repository

commitThe method is the same as that of ordinary submission. And then,moduleThe warehouse looks like this:

Modifying submodules

  • Switch to the submodule branch where you want to modify the code, modify the corresponding code, push (same as normal repository)

  • Pull server code and merge it into local Module (target repository branch)

    git submodule update --remote --merge

  • Modify target warehouse, push

Clone a belt module project

Here you will clone a strip module project. When you receive such a project, you will get the directory containing the subproject, but no files in it, as follows:

The subModule directory exists, but is empty. You must run two commands: git submodule init to initialize your local configuration file, and git submodule update to pull all data from that project and check out the appropriate commit listed in your upper project:

$ git submodule init
Submodule 'submodule' (https://gitee.com/Hancoson/submodule.git) registered for path 'submodule'
$ git submodule update
Submodule path 'submodule': checked out '471741e958c2ef0096ad5971c264041a9295ce3b'

Your subModule subdirectory is now in the exact state that you submitted it earlier. Git subModule Update you must do this every time you pull a submodule change from the main project.

subsequent

Git submodule *