Git版本2.19引入了git range-diff，它应该用于比较两个提交范围。我一直在阅读文档，但无法了解此新功能的用途。
我检查了官方Git documentation，但在理解其语法（省略标志）方面遇到困难：
git range-diff ( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> )
rev1和rev2是什么？
每个人都可以解释一下它们何时有用吗？
答案 0 :(得分：9)
我实际上还没有使用过它们，但是它们是对旧的my_data2 <- my_data[,1:2] %>%
left_join(sales_days)
head(my_data2)
# A tibble: 6 x 4
DW_DATE_ID day_num sales_day remaining_sales
<dttm> <int> <dbl> <dbl>
1 1993-04-01 00:00:00 1 1 64
2 1993-04-02 00:00:00 2 0 63
3 1993-04-03 00:00:00 3 0 63
4 1993-04-04 00:00:00 4 1 63
5 1993-04-05 00:00:00 5 1 62
6 1993-04-06 00:00:00 6 1 61
流程的改进，用于分析/比较某些上游或下游变更集与您现有的变更集。为了使范围集有用，我们需要一些“这里是我的提交”和“这里是他们的提交”，并尽可能简单地表达出来。
一个 range1 range2 集应写为，例如：
git cherry*如果有的话，例如：
git range-diff theirs~5..theirs ours~4..ours
其中 T1--T2--T3--T4--T5 <-- theirs
/
...--o--* <-- base
\
O1--O2--O3--O4 <-- ours
的提交是“我们的”，而O的提交是“他们的”。
鉴于此配置完全相同，我们还可以编写：
T（请注意三个点）。 （例如，这是git range-diff theirs...ours # or ours...theirs
使用的语法。）
或者，再次鉴于这种情况，我们可以这样写：
git rev-list --cherry-mark --left-right git range-diff base theirs ours # or base ours theirs
是他们和我们俩的出发点，避免了倒数5。
如果情况更加复杂-如图所示：
base三点语法和 X1--T1--T2--T3 <-- theirs
/
...--o--* <-- base
\
Y1--Y2--O1--O2--O3--O4 <-- ours
这种语法都不起作用，因此最好使用两组范围（base ours theirs）。
答案 1 :(得分：5)
解决合并冲突（在rebase，cherry-pick等之后），范围差异变得非常有用，
尤其是当您有多个冲突的提交，并且您要确保在此过程中没有意外破坏某些东西时。
在分支中进行多次提交的情况下，通常会发生这种情况。
假设我们有一个名为“我们的”的分支，而我们的分支位于master分支的后面：
m1-m2-m3-m4 <- "master" branch
\
o1-o2-o3 <- "our" current branch
在重新定基之前，我们会对分支进行备份（只是将复制分支命名为“ our_bkp”）
git branch our_bkp
现在我们开始与主人重新定基
git rebase master
解决提交“ o1”上的一些合并冲突...
注意：如果在“ o2”或“ o3”中还使用/更改了“ o1”上的冲突文件，
那么我们也必须重新解决它们上的相同合并冲突。
现在，让我们说说，在完成了繁琐的重新设置过程之后，我们有了以下内容：
_<- branch "master"
/
m1-m2-m3-m4-o1'-o2'-o3' <- branch "our" (after rebase)
\
o1-o2-o3 <- branch "our_bkp"
由于存在许多合并冲突，因此我们是否遗漏了某些东西并不清楚。
这是range-diff发光的地方。
要确保我们没有错过任何更改或意外损坏任何东西，我们可以简单地 将分支的旧版本与较新版本中的提交进行比较：
git range-diff our_bkp~3..our_bkp our~3..our
或
git range-diff o1..o3 o1'..o3'
如果差异仅与冲突的部分有关，那么我们很好，除了它们之外没有任何改变。
但是，如果我们看到其他意外的差异，则我们或git做错了什么，我们需要对其进行修复。
注释
o1..o3是指这些提交的次数，例如：0277a5883d132bebdb34e35ee228f4382dd2bb7..e415aee3fa53a213dc53ca6a7944301066b72f24 ~3中的our_bkp~3说到git来获取3分支之前的our_bkp提交。将数字替换为分支上的提交数量，当然不要忘了用备份分支的名称替换分支名称our_bkp。答案 2 :(得分：3)
在Git中，“范围”是一对修订标识符（开始和结束）。
git range-diff的第一种用法是<range1> <range2>。由于我们知道范围是一对修订标识符，所以一些可能的示例是：
abc1234..def5678 9876foo..5432bar
HEAD..def5678 my_release_1_1..my_release_1_2
当四个修订标识符中的某些标识符彼此相同时，其他两种用法是为了方便起见。即：
abc..def def..abc之类的情况，您只需指定def...abc。abc..def abc..xyz之类的情况，您可以指定abc def xyz。在我看来，这是一种常见的情况：您想比较从同一点开始的两个范围。答案 3 :(得分：0)
您可以在git range-diff中看到的命令here comparing two patches在Git 2.23（2019年第三季度）中得到了重新访问，以便更轻松地识别补丁所涉及的文件的哪个部分。
请参见commit 499352c，commit 444e096，commit b66885a，commit 430be36，commit e1db263，commit 44b67cb，commit 1ca6922，{{3} }，commit ef283b3（2019年7月11日）和commit 80e1841，commit 877a833，commit 570fe99，commit 85c3713，commit d6c88c4（2019年7月8日）之前，{ {3}}。
（由commit 5af4087在Thomas Gummerer (tgummerer)中合并，2019年7月25日）
range-diff：将文件名添加到内部差异在范围差异中，并不总是清楚某个
funcname属于哪个文件 内部差异所属，因为差异标头（或上一次提交中添加的节标头）在range-diff中并不总是可见。将文件名添加到内部diffs标头中，因此它始终对 用户。
这还允许我们将文件名+函数名添加到外部 使用自定义的userdiff模式比较diff头文件，这将完成 在下一次提交中。
range-diff：将标题添加到外部大块标题中将我们在先前提交中介绍的节标题/大标题添加到外部diff的大标题中。
这样可以更轻松地了解我们实际要查看的更改。例如，外部的大块头现在可能看起来像：@@ Documentation/config/interactive.txt而以前只是
@@并没有为随后的更改提供很多背景信息。
以Junio C Hamano -- gitster --为例。
并且：
range-diff：添加节头而不是diff头
当前，range-diff使内部diff的diff头保持完整（除了以index开头的剥离线）。
这个diff标头有点有用，尤其是当文件变得不同时 名称在不同范围内。但是实际上并不需要保留整个diff标头。
我们目前这样做的主要原因可能是因为它很容易做到。引入一个新的范围diff块头，将其用“
##”括起来，类似于diff块中的行号如何用“@@”括起来，并提供人类可读的确切发生信息到文件，包括文件名。通过提供更简洁的内容，可以提高range-diff的可读性 给用户的信息。
例如，如果在一次迭代中重命名了文件，但在另一次迭代中未重命名，则标头的差异会非常嘈杂。
但是，单行的差异很简洁，应该更容易理解。
同样，commit 43ba21c提供了一个示例：
git range-diff --no-color --submodule=log topic...renamed-file >actual && sed s/Z/\ /g >expected <<-EOF && 1: 4de457d = 1: f258d75 s/5/A/ 2: fccce22 ! 2: 017b62d s/4/A/ @@ Metadata ZAuthor: Thomas Rast <trast@inf.ethz.ch> Z Z ## Commit message ## - s/4/A/ + s/4/A/ + rename file Z - ## file ## + ## file => renamed-file ## Z@@ Z 1 Z 2