likes
comments
collection
share

git subtree跨工程共用代码

作者站长头像
站长
· 阅读数 75

背景

前端工程拆分过程中，项目A与项目B存在共用模块，在项目A或B中修改，需要同步到另一个项目中

方案对比

  1. copy 修改完成后，复制粘贴到另一个项目，简单快捷

缺点：

  • 效率低
  • 不利于团队协作
  • 易出现遗漏
  • 不同项目存在差别，复制过去需要重新调试
  1. npm依赖包

缺点：

  • 管理困难，npm发布一般是专人负责
  • 流程繁琐，修改-发布-package更新-调试-有问题后重复以上步骤emm~
  1. 微前端、monorepo，跟目前解决的问题不太适用
  2. git submodule与subtree

  • git submodule

    • 允许其他的仓库指定以一个commit嵌入仓库的子目录
    • 仓库 clone下来需要 init 和 update
    • 会产 .gitmodule 文件记录 submodule 版本信息
    • git submodule 删除起来比较费劲

  • git subtree

    • 避免以上问题
    • 管理和更新流程比较方便
    • git subtree合并子仓库到项目中的子目录。不用像submodule那样每次子项目修改了后要init和update 。万一哪次没update就直接add . 将.gitmodule 也 commit上去就悲剧了
    • git v1.5.2以后建议使用git subtree
    • 对主项目是无感知的，只是一个普通的文件夹

Subtree使用

subtree 的作用就是可以实现一个仓库作为其他仓库的子仓库，对于主项目来说，另一个项目只作为主项目的一个子目录而存在

git subtree跨工程共用代码

新增子项目

现有项目A和B地址为http://A.git和http://B.git,子项目地址为http://child.git

在项目A和B中执行

$ git subtree add --prefix=src/child http://child.git develop --squash
  • --squash 参数表示不拉取历史信息，而只生成一条 commit >信息。
  • = 后面的 src/child 是子项目 clone 后在本地的目录名
  • develop 指的是子项目的分支名> 项目A和B中会新增src/child,内容为child.git仓库 develop分支最新内容，在A中修改child后，
push&pull
$ git subtree push --prefix=src/child http://child.git develop

会将最新修改推送到child.git仓库，然后在项目B中执行

$ git subtree pull --prefix=src/child http://child.git develop --squash

拉取最新代码(add时加--squash，pull也要加)，就像普通的git pull push操作一样，这样，就做到了child在两个项目中的同步，其他时候src/child对主项目A和B来说就是一个普通文件夹。

问题

  1. git subtree push的时间会不断增加 git subtree跨工程共用代码

原因：git subtree add时会在commit中记录当前commitId，后续每次push都会基于这一次commitId从后续提交中抽离出src/child目录相关的提交，然后将抽离的内容提交到child.git

解决：$ git subtree split --prefix=src/child --rejoin ,会重新记录commitId,下一次push从split开始

原理 www.bianchengquan.com/article/145…

subtree到底如何遍历提交的

相信这个问题是很多人对subtree最大的疑问，因为引用subtree的工程是不保存任何和subtree工程相关的信息的，因此每次输入命令都需要带上git地址和分支名，那subtree push是如何做到只遍历到split或add的commit就停止的呢，他怎么能知道哪个commit是split的commit，我们通过查看源码分析这个问题。 在Mac上subtree脚本文件为/Library/Developer/CommandLineTools/usr/libexec/git-core/git-subtree，这份脚本代码是可以直接调试的。

cmd_push () {
	if test $# -ne 2
	then
		die "You must provide <repository> <ref>"
	fi
	ensure_valid_ref_format "$2"
	if test -e "$dir"
	then
		repository=$1
		refspec=$2
		echo "git push using: " "$repository" "$refspec"
		localrev=$(git subtree split --prefix="$prefix") || die
		git push "$repository" "$localrev":"refs/heads/$refspec"
	else
		die "'$dir' must already exist. Try 'git subtree add'."
	fi
}

subtree push命令入口在cmd_push方法内，可以看出，这个方法实际上执行了一下subtree split，并把这个命令的输出push到subtree工程的git仓库，即subtree push = subtree split + git push，通过实验可以知道，subtree split在不带--rejoin参数的情况，输出是一个commitId，也就是这个命令生成了一个新commit。 从之前subtree split的执行结果可以看出，subtree split就是把包含subtree目录的提交摘出来的这个步骤，--branch就是把摘出来的提交放入一个指定分支，--rejoin就是不产生新分支，而是直接把摘出来的提交重新合入当前分支。 git subtree跨工程共用代码 上述分析并没有解答我们的问题，subtree push是怎么找到split的提交的，继续看subtree split的代码。 这里由于split方法比较长，只贴出部分

cmd_split () {
	debug "Splitting $dir..."
	cache_setup || exit $?

	if test -n "$onto"
	then
		debug "Reading history for --onto=$onto..."
		git rev-list $onto |
		while read rev
		do
			# the 'onto' history is already just the subdir, so
			# any parent we find there can be used verbatim
			debug "  cache: $rev"
			cache_set "$rev" "$rev"
		done
	fi

	unrevs="$(find_existing_splits "$dir" "$revs")"

	# We can't restrict rev-list to only $dir here, because some of our
	# parents have the $dir contents the root, and those won't match.
	# (and rev-list --follow doesn't seem to solve this)
	grl='git rev-list --topo-order --reverse --parents $revs $unrevs'
	revmax=$(eval "$grl" | wc -l)
	revcount=0
	createcount=0
	extracount=0
	eval "$grl" |
	while read rev parents
	do
		process_split_commit "$rev" "$parents" 0
	done || exit $?

这里有两句重要代码，一个是find_existing_splits的调用，一个是git rev-list的调用，看方法名就知道，这个find_existing_splits方法就是用来找split的。

find_existing_splits () {
	debug "Looking for prior splits..."
	dir="$1"
	revs="$2"
	main=
	sub=
	local grep_format="^git-subtree-dir: $dir/*$"
	if test -n "$ignore_joins"
	then
		grep_format="^Add '$dir/' from commit '"
	fi
	git log --grep="$grep_format" \
		--no-show-signature --pretty=format:'START %H%n%s%n%n%b%nEND%n' $revs |
	while read a b junk
	do
		case "$a" in
		START)
			sq="$b"
			;;
		git-subtree-mainline:)
			main="$b"
			;;
		git-subtree-split:)
			sub="$(git rev-parse "$b^0")" ||
			die "could not rev-parse split hash $b from commit $sq"
			;;
		END)

懂shell的同学应该都明白了，大概翻译一下就是commit message带有git-subtree-dir、git-subtree-mainline、git-subtree-spilt的提交就认为是split的提交，subtree add的提交记录和subtree split类似也符合这个规则，所以这个规则能同时找出split提交的add提交。

从上面的git树可以看到，split提交是由两个提交合成的，并且split提交message里也有记录，一个是subtree-mainline，一个是subtree-split，找到split提交后，会从split的提交message里找到subtree-mainline和subtree-split的commitId，把这两个提交输出，作为git rev-list的参数。 git subtree跨工程共用代码 再查一下git rev-list的功能，整个命令git rev-list --topo-order --reverse --parents $revs $unrevs，意思是输出所有能到达revs的commit且不能到达\unrevs的commit，即在revs和revs和revs和unrevs之间的commit，其中revs是在脚本开始执行时赋值的，为执行命令时所在的commitId，revs是在脚本开始执行时赋值的，为执行命令时所在的commitId，revs是在脚本开始执行时赋值的，为执行命令时所在的commitId，unrevs则是find_existing_splits方法找到的commitId，就是这样，subtree push能只遍历当前提交和上一个split或add之间的提交。

项目使用

  1. 尽量在一个项目中对child项目做提交，其他项目只pull,不会产生很多merge记录,保持commit纯净
  2. 定期split，防止push时间过长
  3. 有问题删掉subtree重新add
  4. git 列出所有的 subtree

git log | grep git-subtree-dir | tr -d ' ' | cut -d ":" -f2 | sort | uniq

转载自:https://juejin.cn/post/7080931951808348168
评论
请登录