Git submodule 的精准用法 - Revision history

Mwroot at 13:43, 22 July 2026

2026-07-22T13:43:24Z

← Older revision		Revision as of 21:43, 22 July 2026
Line 46:		Line 46:
	: 它记录的不是模糊的“使用最新版”，而是，这套配置经过测试时，各插件分别停留在哪个准确版本。这相当于给插件环境加了一把版本锁。		: 它记录的不是模糊的“使用最新版”，而是，这套配置经过测试时，各插件分别停留在哪个准确版本。这相当于给插件环境加了一把版本锁。
	; 整体回滚		; 整体回滚
	: ~~主仓库回滚到 abc1234，子仓库也会恢复到当时的状态。普通嵌套~~ <code>git clone</code> ~~做不到这一点。即使主配置回到一个月前，插件仍可能停留在今天的新版本。~~		: 主仓库回滚到过去某个 commit 后，再执行 <code>git submodule update --init --recursive</code>，各子仓库会恢复到该主仓库 commit 当时所记录的版本。普通嵌套 <code>git clone</code> 做不到这一点。
	; 异地完整复现		; 异地完整复现
	: <code>git clone --recurse-submodules URL PATH</code>，恢复出来的插件环境与原电脑一致。		: <code>git clone --recurse-submodules URL PATH</code>，恢复出来的插件环境与原电脑一致。
Line 55:		Line 55:
	<syntaxhighlight lang="bash" line>		<syntaxhighlight lang="bash" line>
	## 配置		## 配置
	git config diff.submodule lo		git config diff.submodule log
	git config status.submodulesummary 1		git config status.submodulesummary 1

Line 93:		Line 93:

	## 移机		## 移机
	git clone --recurse-submodules 主仓库URL ~/.emacs.d # ~~一次搞定，或~~		git clone --recurse-submodules 主仓库URL ~/.emacs.d
	git pull && git submodule update --init --recursive ~~# 两次搞定~~
			## 同步
			git pull
			git submodule update --init --recursive
	</syntaxhighlight>		</syntaxhighlight>

Line 101:		Line 104:
	* 一次升级一个插件，一个插件形成一个独立提交。		* 一次升级一个插件，一个插件形成一个独立提交。
	* submodule 经常处于 detached HEAD 是正常的。这是版本锁定的正常状态。		* submodule 经常处于 detached HEAD 是正常的。这是版本锁定的正常状态。
	* ~~git~~ submodule ~~搞定源码仓库的版本关系，它不是包管理器，依赖项需要各软件自行安装~~		* Git submodule 只管理源码仓库及其版本关系，它不是 Emacs 包管理器；插件依赖仍需自己检查并安装或加入 submodule。

Mwroot: /* 概念 */

2026-07-22T13:32:43Z

概念

← Older revision		Revision as of 21:32, 22 July 2026
Line 39:		Line 39:

	这种设计有两个好处：		这种设计有两个好处：
	# 不把别人写的几百个插件源码文件伪装成自己的文件		* 不把别人写的几百个插件源码文件伪装成自己的文件
	# 又能让配置仓库精确声明自己依赖哪个插件版本		* 又能让配置仓库精确声明自己依赖哪个插件版本

	submodule 最重要的价值：		submodule 最重要的价值：

Mwroot: /* 概念 */

2026-07-22T13:31:56Z

概念

← Older revision		Revision as of 21:31, 22 July 2026
Line 21:		Line 21:

	submodule 还会记录一条指向某个 commit 的 gitlink。		submodule 还会记录一条指向某个 commit 的 gitlink。

	{\|class="wikitable"		{\|class="wikitable"
	! 仓库		! 仓库
Line 39:		Line 38:
	\|}		\|}

	~~这种设计避免了两个问题：~~		这种设计有两个好处：

	# 不把别人写的几百个插件源码文件伪装成自己的文件		# 不把别人写的几百个插件源码文件伪装成自己的文件
	# 又能让配置仓库精确声明自己依赖哪个插件版本		# 又能让配置仓库精确声明自己依赖哪个插件版本

	submodule ~~最重要的价值~~		submodule 最重要的价值：
	# 固定插件版本。它记录的不是模糊的“使用最新版”，而是，这套配置经过测试时，各插件分别停留在哪个准确版本。这相当于给插件环境加了一把版本锁。		; 固定插件版本
	~~# 整体回滚。主仓库回滚到~~ abc1234，子仓库也会恢复到当时的状态。普通嵌套 <code>git clone</code> 做不到这一点。即使主配置回到一个月前，插件仍可能停留在今天的新版本。		: 它记录的不是模糊的“使用最新版”，而是，这套配置经过测试时，各插件分别停留在哪个准确版本。这相当于给插件环境加了一把版本锁。
	~~# 异地完整复现。~~<code>git clone --recurse-submodules URL PATH</code>，恢复出来的插件环境与原电脑一致。		; 整体回滚
	~~# 明确记录插件升级。使用~~ submodule 后，升级插件会被主仓库识别为一次正式变化，这让插件升级变成一种可查看、可测试、可提交、可撤销的操作。		: 主仓库回滚到 abc1234，子仓库也会恢复到当时的状态。普通嵌套 <code>git clone</code> 做不到这一点。即使主配置回到一个月前，插件仍可能停留在今天的新版本。
			; 异地完整复现
			: <code>git clone --recurse-submodules URL PATH</code>，恢复出来的插件环境与原电脑一致。
			; 明确记录插件升级
			: 使用 submodule 后，升级插件会被主仓库识别为一次正式变化，这让插件升级变成一种可查看、可测试、可提交、可撤销的操作。

	== 工作流 ==		== 工作流 ==

Mwroot at 13:29, 22 July 2026

2026-07-22T13:29:43Z

← Older revision		Revision as of 21:29, 22 July 2026
Line 1:		Line 1:
	Git submodule 适合这种情况：主项目需要别的子项目，主项目需要管理子项目的版本。git clone ~~的子项目只是碰巧存在于这台电脑。Git~~ submodule，子项目是主项目正式声明的一项依赖，正式记录插件的 URL、保存路径和准确版本。Git submodule 的本质是，放弃包管理器的一部分自动化，换取透明、固定、可控和可复现。对于大量、频繁更新的子项目，手工管理会比较繁琐；对于少量精选、长期固定、谨慎升级的子项目，非常合适。		Git submodule 适合这种情况：主项目需要别的子项目，主项目需要管理子项目的版本。git clone 的子项目只是碰巧存在于这台电脑；而 Git submodule，子项目是主项目正式声明的一项依赖，正式记录插件的 URL、保存路径和准确版本。Git submodule 的本质是，放弃包管理器的一部分自动化，换取透明、固定、可控和可复现。对于大量、频繁更新的子项目，手工管理会比较繁琐；对于少量精选、长期固定、谨慎升级的子项目，非常合适。

	== 概念 ==		== 概念 ==

Mwroot at 13:27, 22 July 2026

2026-07-22T13:27:45Z

← Older revision		Revision as of 21:27, 22 July 2026
Line 1:		Line 1:
	Git submodule ~~适合这种情况：主项目需要别的子项目，主项目需要管理子项目的版本。普通 git~~ clone 的子项目只是碰巧存在于这台电脑。Git submodule，子项目是主项目正式声明的一项依赖，正式记录插件的 URL、保存路径和准确版本。Git submodule 的本质是，放弃包管理器的一部分自动化，换取透明、固定、可控和可复现。对于大量、频繁更新的子项目，手工管理会比较繁琐；对于少量精选、长期固定、谨慎升级的子项目，非常合适。		Git submodule 适合这种情况：主项目需要别的子项目，主项目需要管理子项目的版本。git clone 的子项目只是碰巧存在于这台电脑。Git submodule，子项目是主项目正式声明的一项依赖，正式记录插件的 URL、保存路径和准确版本。Git submodule 的本质是，放弃包管理器的一部分自动化，换取透明、固定、可控和可复现。对于大量、频繁更新的子项目，手工管理会比较繁琐；对于少量精选、长期固定、谨慎升级的子项目，非常合适。

	== 概念 ==		== 概念 ==

Mwroot at 13:27, 22 July 2026

2026-07-22T13:27:37Z

← Older revision		Revision as of 21:27, 22 July 2026
Line 1:		Line 1:
	Git submodule 适合这种情况：主项目需要别的子项目，主项目需要管理子项目的版本。普通 git clone ~~子项目只是碰巧存在于这台电脑。Git~~ submodule，子项目是主项目正式声明的一项依赖，正式记录插件的 URL、保存路径和准确版本。Git submodule 的本质是，放弃包管理器的一部分自动化，换取透明、固定、可控和可复现。对于大量、频繁更新的子项目，手工管理会比较繁琐；对于少量精选、长期固定、谨慎升级的子项目，非常合适。		Git submodule 适合这种情况：主项目需要别的子项目，主项目需要管理子项目的版本。普通 git clone 的子项目只是碰巧存在于这台电脑。Git submodule，子项目是主项目正式声明的一项依赖，正式记录插件的 URL、保存路径和准确版本。Git submodule 的本质是，放弃包管理器的一部分自动化，换取透明、固定、可控和可复现。对于大量、频繁更新的子项目，手工管理会比较繁琐；对于少量精选、长期固定、谨慎升级的子项目，非常合适。

	== 概念 ==		== 概念 ==

Mwroot at 13:27, 22 July 2026

2026-07-22T13:27:18Z

@@ Line 1: / Line 1: @@
-Git submodule 适合这种情况：
+Git submodule 适合这种情况：主项目需要别的子项目，主项目需要管理子项目的版本。普通 git clone 子项目只是碰巧存在于这台电脑。Git submodule，子项目是主项目正式声明的一项依赖，正式记录插件的 URL、保存路径和准确版本。Git submodule 的本质是，放弃包管理器的一部分自动化，换取透明、固定、可控和可复现。对于大量、频繁更新的子项目，手工管理会比较繁琐；对于少量精选、长期固定、谨慎升级的子项目，非常合适。
 == 概念 ==
@@ Line 100: / Line 98: @@
 * 不要修改插件原始仓库。不应把自己的配置写进子仓库。
 * 一次升级一个插件，一个插件形成一个独立提交。
+* submodule 经常处于 detached HEAD 是正常的。这是版本锁定的正常状态。
-== detached ==
+* git submodule 搞定源码仓库的版本关系，它不是包管理器，依赖项需要各软件自行安装

Mwroot: /* 概念 */

2026-07-22T13:22:51Z

概念

← Older revision		Revision as of 21:22, 22 July 2026
Line 47:		Line 47:

	submodule 最重要的价值		submodule 最重要的价值
	# 固定插件版本，它记录的不是模糊的“使用最新版”，而是，这套配置经过测试时，各插件分别停留在哪个准确版本。这相当于给插件环境加了一把版本锁。		# 固定插件版本。它记录的不是模糊的“使用最新版”，而是，这套配置经过测试时，各插件分别停留在哪个准确版本。这相当于给插件环境加了一把版本锁。
	# 整体回滚。主仓库回滚到 abc1234，子仓库也会恢复到当时的状态。普通嵌套 <code>git clone</code> 做不到这一点。即使主配置回到一个月前，插件仍可能停留在今天的新版本。		# 整体回滚。主仓库回滚到 abc1234，子仓库也会恢复到当时的状态。普通嵌套 <code>git clone</code> 做不到这一点。即使主配置回到一个月前，插件仍可能停留在今天的新版本。
	# 异地完整复现。<code>git clone --recurse-submodules URL PATH</code>，恢复出来的插件环境与原电脑一致。		# 异地完整复现。<code>git clone --recurse-submodules URL PATH</code>，恢复出来的插件环境与原电脑一致。

Mwroot: /* 概念 */

2026-07-22T13:22:29Z

概念

← Older revision		Revision as of 21:22, 22 July 2026
Line 16:		Line 16:

	.gitmodules 内容大致如下：		.gitmodules 内容大致如下：

	<syntaxhighlight lang="ini">		<syntaxhighlight lang="ini">
	[submodule "travel/packages/vertico"]		[submodule "travel/packages/vertico"]

Mwroot at 13:21, 22 July 2026

2026-07-22T13:21:56Z

← Older revision		Revision as of 21:21, 22 July 2026
Line 1:		Line 1:
	Git submodule 适合这种情况：		Git submodule 适合这种情况：
	* 主项目需要别的子项目		* 主项目需要别的子项目
	* ~~主项目管理别的子项目的版本~~		* 主项目管理子项目的版本

	== 概念 ==		== 概念 ==