工具，以查找由以前的更改或工作区中的更改更改的最新提交。

Question

TL;DR

(你可能会误解这一点，所以最好跳到下一节;)

我希望找到(以前的)提交修补程序(提交或分阶段/非分阶段的工作区更改)将更改。

TL；博士:继续阅读，但跳过的“背景”.

背景

我会在这里描述我的工作流程，这样你就可以理解我需要什么了。

在我的开发分支上，我经常在很多WIP提交中提交一些小的更改。当我对我的总体变化感到满意时，我就会以交互的方式重新建立所有这些WIP承诺，以建立一个干净的历史。我将提交压缩到其他提交中，并编写详细的提交消息。

在三种情况下，我想指出以前的提交应该被压缩到另一个提交中。

• 当我注意到我在以前的WIP提交中引入了一个bug时
• 当我想显式地将最近的更改合并到某个WIP提交时
• 提到提交ID，它在bug修复的提交消息中引入了一个bug

然后，我做了一个提交，注意提交，修改(bugfix)必须压入。

历史可能是这样的：

[WIP] Fixed some bug [SQUASH with '[WIP] Made some sloppy change'] (A)
...
[WIP] Made some sloppy change (B)
...

(有时我在4小时内提交15次以上)

因为我经常做这样的小补丁，所以我想到了一个自动化的解决方案。

我想知道的是

当一个补丁..。

• 删除并添加行(更改)，我希望得到已引入或最近更改该行的提交
• 添加行，我希望在最近更改或引入的插入之前和之后获得行的提交
• 仅移除行，我希望得到添加或最近修改这些行的提交

我是怎么用手动方式做这件事的

TL;DR：跳过这一节，继续阅读章节.

在准备提交(A)时，我以这样的方式搜索提交(B)：

• 检查本地更改并通过发出记住影响行号
  • 如果更改尚未执行，则为git diff。
  • 如果更改已经完成，则为git log -1 -p

​

• 通过发出查找在修补程序生成之前影响记忆行的提交
  • 如果更改尚未执行，则为git blame HEAD -- path/to/file。
  • 如果更改已经完成，则为git blame HEAD~1 -- path/to/file

​

之后，在这两种情况下，我将使用git log <COMMIT ID>获得那些提交ID的提交消息。

添加和更改示例(尚未完成的更改)：

这是补丁程序( git diff )

diff --git a/Gruntfile.js b/Gruntfile.js
index 9af9384..380726c 100644
--- a/Gruntfile.js
+++ b/Gruntfile.js
@@ -82,6 +82,7 @@ module.exports = function(grunt) {
                less: {
                        build: {
                                options: {
+                                       dumpLineNumbers: "comments",
                                        paths: ["target/"]
                                },

@@ -141,7 +142,7 @@ module.exports = function(grunt) {

                        src: {
                                files: 'src/**',
-                               tasks: ['copy:source-tree', 'copy:devel-source-tree']
+                               tasks: ['copy:source-tree', 'copy:devel-source-tree', 'less']
                        }
                }
        });

这里是 git blame -L82,+8 HEAD -- Gruntfile.js 和 git blame -L142,+8 HEAD -- Gruntfile.js

f39f25c0 (Nobody 2014-05-17 16:08:20 +0200 82)          less: {
f39f25c0 (Nobody 2014-05-17 16:08:20 +0200 83)                  build: {
f39f25c0 (Nobody 2014-05-17 16:08:20 +0200 84)                          options: {
f39f25c0 (Nobody 2014-05-17 16:08:20 +0200 85)                                  paths: ["target/"]
f39f25c0 (Nobody 2014-05-17 16:08:20 +0200 86)                          },
f39f25c0 (Nobody 2014-05-17 16:08:20 +0200 87)
f39f25c0 (Nobody 2014-05-17 16:08:20 +0200 88)                          files: {
f39f25c0 (Nobody 2014-05-17 16:08:20 +0200 89)                                          "target/styles.css": "src/less/styles.less"


e2e46b59 (Nobody 2014-05-03 10:30:34 +0200 142)                         src: {
e2e46b59 (Nobody 2014-05-03 10:30:34 +0200 143)                                 files: 'src/**',
e2e46b59 (Nobody 2014-05-03 10:30:34 +0200 144)                                 tasks: ['copy:source-tree', 'copy:devel-source-tree']
f9a635c0 (Nobody 2014-04-21 16:03:38 +0200 145)                         }
f9a635c0 (Nobody 2014-04-21 16:03:38 +0200 146)                 }
f9a635c0 (Nobody 2014-04-21 16:03:38 +0200 147)         });
5128dcdc (Nobody 2014-04-20 12:56:05 +0200 148)
f9a635c0 (Nobody 2014-04-21 16:03:38 +0200 149)         grunt.task.loadTasks("tasks/");

这些是提交消息( git log --oneline -1 f39f25c0 和 git log --oneline -1 e2e46b59 )

f39f25c [WIP] * Changed to less (left .css file)
e2e46b5 [WIP] * Changed watch configuration

现在我知道了，我必须把两个大块头分别提到个人提交。

解决方案

是的，，我读了git-blame手册页，但是我没有找到一个合适的选项来做这件事(我确信我可能遗漏了什么)。

是的，，我也尝试过在互联网上搜索这个。但是，嗯，我花了一页的时间来描述它--我应该如何制定Google搜索的黄金表达式来找到它呢？

是的，，正如您在下一节中所看到的，我有自己的想法。

我的方法

我将创建一个脚本来解析git log -p或git diff生成的补丁。它将使用中的“我想知道的”部分中的规则输出补丁所影响的所有行号。然后，bash脚本通过检查git blame HEAD[~1]输出来查找提交ID，提取提交ID。另一个步骤可以是，用刚刚找到的提交消息来修饰整个补丁输出(多个块和文件)。

(实际上，目前我正在编写一个执行补丁解析的Python脚本)

替代方法

也许可以通过从git blame -- <FILE>和git blame HEAD -- <FILE>中提取commit列，并将这两个输出输入diff，然后为00000000提供grep -C <N>ing等来查找受影响的提交ID。

但我认为这是脆弱的，不像上面的方法那么可靠。我也需要分析罪魁祸首的差异。

(我已经试过了。最困难的部分是diff输出解析。)

尽量把它简化为一个问题。

是否有一个标准的Git工具，通过显示通过应用提交而更改的提交，将git指责的功能与git日志提供的数据结合起来？

我希望我的问题足够清楚。:)

特别一点。

我确定，我是

Answer 1

为了帮助后面的部分，您应该真正了解git rebase -i --autosquash。Autosquash重基将寻找特别格式化的提交，以自动重新排序时，您的提交，并将他们标记为壁纸/修复。来自git help rebase

   --autosquash, --no-autosquash
       When the commit log message begins with "squash! ..." (or "fixup!
       ..."), and there is a commit whose title begins with the same ...,
       automatically modify the todo list of rebase -i so that the commit
       marked for squashing comes right after the commit to be modified,
       and change the action of the moved commit from pick to squash (or
       fixup).

       This option is only valid when the --interactive option is used.

       If the --autosquash option is enabled by default using the
       configuration variable rebase.autosquash, this option can be used
       to override and disable this setting.

至于自动查找最后的变化，自动完成它将永远是脆弱的。

鉴于以下历史：

[WIP] Fixed sloppy change     (A)
[WIP] Intermediate change     (B)
[WIP] Sloppy change           (C)

如果您有一个中间提交(B)，它修改与(A)和(C)相同的行，但您不希望将commit (A)与(B)合并，而是与旧的(C)合并，则很容易意外地压缩错误的提交。

而且，通常情况下，您想要合并的提交不会与当前的更改发生冲突，因此任何魔法都不能使脚本预言到您想要做的事情。因此，编写这一部分具有边际价值，相反，我发现使用基于GUI的历史浏览器极大地帮助了这一步(我在Linux上使用了gitg，在Mac上使用了gitx，但是任何历史浏览器都可以)。