Common commands
| Order | illustrate |
|---|---|
git submodule add <url> <本地路径> |
Add submodule |
git submodule update --init --recursive |
After adding a submodule, synchronize the submodule content |
git clone <url> --recurse-submodules |
Clone project with submodules |
git submodule init |
Initialize submodule |
git submodule update |
Update submodule |
git submodule sync --recursive |
Submodule address change |
git submodule deinit <project> |
Delete submodule |
background
When browsing open source libraries, you often see references to the following submodules.
Submodules are usually used when the project is relatively complex and needs to be split, and the project has reference relationships. Usually after splitting a project, I only need to pay attention to the changes in my own project, and do not need to pay attention to the changes made to the referenced projects.
Usually after splitting like this, the project will not be in one gitwarehouse. At this time, submoduleit will be much clearer and more convenient to manage the code warehouse.
Basic usage
Add submodule
git submodule add <url> <本地路径>,example:
git submodule add https://github.com/grassto/example.git example
After the execution is completed, it is found that there is an additional exampledirectory in the warehouse directory, but there are no files in it. At this time, you need to execute again:
git submodule update --init --recursive
At this time, you will see the following changes in the warehouse:
You can see the following content in .gitmodules
[submodule "example"]
path = example
url = https://github.com/grassto/example.git
In addition, .git/configthere will be an additional piece of information about submodules in the
[submodule "example"]
active = true
url = https://github.com/grassto/example.git
At the same time, .git/mudulesthere will be an additional .git/mudules/exampledirectory under the directory.
Clone project with submodules
cloneYou can only pull the code of the main project directly . You need to execute more submodulerelated commands, as follows:
git clone https://github.com/grassto/example.git --recurse-submodules
Clone first, then initialize the submodule pull
git clone
git submodule init
git submodule update
Update submodule
git submodule update
git submodule update --remote
Without adding --remoteparameters, only update the submodule to the latest version used by the repository, for example:
The submodule has been developed by itself and updated to version 1.0, , but at this time my main warehouse only used version . After using update, I found that I could only update to version 1.1.1.21.0git submodule update1.0
If the parameter is added --remote, it will be directly updated to the latest version of the submodule warehouse.
A simple understanding is that the main warehouse uses a specific version of the sub-module warehouse. If you want to update, the main warehouse needs to actively update and then submit.
Submodule address change
git submodule sync --recursive
If the submodule urlchanges, the execution git submodule updatewill fail. You can use syncto synchronize.
I have never used this, but I saw it on the official website, so I will mention it here.
Delete submodule
git submodule deinit example
git rm example
git commit -m "delete submodule example"
It is recommended to use the above method, of course you can also delete it manually:
- Delete local submodule directory
git rm --cached example
rm -rf example
- Delete
.gitmodulessubmodule information
[submodule "example"]
path = example
https://github.com/grassto/example.git
- Delete
.git/configthe submodule content in the file
[submodule "example"]
active = true
https://github.com/grassto/example.git
- Delete
.gitthe relevant submodule files in the folder
rm -rf .git/modules/example
Summarize
- After using
submodule, if you do not actively update, the project will always use the fixed version ofsubmodulethe module and need to be updated manually (git submodule update --remote). - If you are working on
goor other projects with package management, it is recommended that it is more convenient to use development language tools to do this kind of third-party package management.
other
As a godeveloper, I still recommend using go moduleto do this kind of package management. Here are submodulethe reasons why I use:
Now I am using a package that references a local one and uses replacethe feature. When doing it gitlab CI, I need to synchronize the code repository, which feels inconvenient, so I use git submodulethe code as a submodule. This allows you to use the properties gitlabof GIT_SUBMODULE_STRATEGY: recursive.
If you are also a godeveloper, it is not recommended to use it here, because go moduleprivate libraries can be referenced. There are historical reasons why I use it this way.
The go.mod of the library I need to reference is as follows, modulethe nameis exampleinstead ofgithub.com/example
module example
go 1.18
require ......
When using this module, pull it locally and then replace.
module work
go 1.18
replace example => ./example