如何有效地查看git子模块的更新/基准? [英] How to effectively review git submodule updates/rebases?

问题描述

我们的项目使用git 子模块来固定一个我们的库依赖项.

Our project uses a git submodule to pin one of our library dependencies.

我们定期rebase子模块来跟踪上游的变化，并且在它之上还有一系列的提交，我们不能轻易地向上游提交.

We regularly rebase the submodule to follow upstream changes, and we also have a set of commits on top of it that we cannot easily upstream.

当有人重新设置子模块的基础时，我只会在父存储库的git diff中看到它:

When somebody rebases the submodule, I only see this in the git diff of the parent repo:

--- a/mysubmodule
+++ b/mysubmodule
@@ -1 +1 @@
-Subproject commit abc12345abc12345abc12345abcd12345abc1234
+Subproject commit efg67890efg67890efg67890efg67890efg67890

那不是很有用.当我在子模块中git diff这些提交时，我得到了很多输出，包括所有上游更改，并且我们的提交被掩埋在它们之间.我无法轻易判断在我们自己的提交中执行的某些冲突解决方案是否引入了一些错误.

That is not very useful. When I git diff these commits in the submodule, I get a lot of output, including all of the upstream changes, with our commits on top buried in between. I cannot easily judge whether some of the conflict resolution performed on our own commits introduced some mistakes.

如何有效地对子模块的更改进行代码审查?

推荐答案

使用git range-diff.正是为此目的而设计的，用于查看提交范围.

Use git range-diff. It was designed for exactly this purpose, to review commit ranges.

如果您的父提交回购具有:

If your parent commit repo has:

-Subproject commit abc123
+Subproject commit efg678

然后cd进入子模块并运行(注意三点...):

then cd into your submodule and run (note triple-dots ...):

git range-diff abc123...efg678

---

示例输出说明:

---

Example output explained:

• 每行提交行都显示重新调整前后的提交SHA.
• 顶部的绿线显示上游项目中的新提交.如果您想查看自上次重新调整以来上游发生的变化，请阅读这些内容.
• 黄色行显示了根据重新基准提交的内容.
• 红色行是作为冲突解决方案之一而被删除的提交(例如，如果您向上游项目贡献了一个补丁).
• 绿色行是作为冲突解决方案的一部分添加的提交(例如，如果需要新的自定义才能使您的项目使用新的上游代码).

• 红色和绿色行显示更改的提交，这些更改是作为基准的一部分的(例如，当冲突解决方案必须更改您的顶部提交才能使用修改后的提交时)上游代码).

• Each commit line shows the commit SHA before and after the rebase.
• The green lines at the top show new commits in the upstream project. Read them if you want to want to see what changed upstream since you last rebased.
• Yellow lines show commits unchanged by the rebase.
• Red lines are commits that were removed as part of your conflict resolution (e.g. if you contributed one of your patches-on-top into the upstream project).
• Green lines are commits that were added as part of your conflict resolution (e.g. if a new customisation was necessary to make your project work with the new upstream code).

• Red-and-green lines show commits that were changed as part of the rebase (e.g. when a conflict resolution had to change your commit-on-top in order to work with modified upstream code).

当它们出现时，它们还包括一个普通差异，以便您可以检查差异.

When they appear, they also include a normal diff so you can inspect the difference.

作为审核的一部分，您应特别检查添加/删除顶部提交的外观是否正确(或是否意外删除了某些内容)以及冲突解决方案(红线和绿线)是否正确

As part of your review, you should especially check whether addition/removal of your commits-on-top look right (or if some were accidentally dropped), and whether the conflict resolution (red-and-green lines) looks correct.

这篇关于如何有效地查看git子模块的更新/基准?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！