git - 查找先前更改或工作空间更改更改的最新提交的工具

Question

TL；博士
（你可能会误解这一点，所以最好跳到下一节；）
我想找到（上一个）提交修补程序（提交或分阶段/未分阶段的工作区更改）将更改的内容。
博士：继续阅读，但跳过“背景”…
背景
我将在这里描述我的工作流程，这样你就可以理解我需要什么了。
在我的开发分支上，我经常在许多WIP提交中提交一些小的更改。当我对我的整体更改感到满意时，我会交互地重新平衡所有这些WIP提交，以创建一个干净的历史记录。我将提交压缩到其他提交中，并编写一个详细的提交消息。
有三种情况下，我想注意到前一个提交另一个提交应该被压扁。
当我注意到在之前的WIP提交中引入了一个bug时
当我想显式地将最近的更改合并到某个WIP提交中时
提到在错误修复程序的提交消息中引入错误的提交ID
然后，我做一个提交，注意到必须将更改（错误修复）压入的提交。
历史可能是这样的：

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

（有时我在4小时内犯下超过15次的罪行）
因为我经常做这些小补丁，所以我想到了一个自动化的解决方案。
我想知道的
当一个补丁…
删除并添加行（更改），我希望获取已引入或最近更改该行的提交
添加行，我希望在插入之前和之后获取最近更改或引入的行的提交
仅删除行，我想获取添加或最近修改这些行的提交
我怎么用手动方式
跳过这一节，继续阅读“示例…”一节…
在准备commit (A)时，我按以下方式搜索commit (B)：
检查本地更改并通过发出
git diff如果更改尚未提交
git log -1 -p如果更改已经完成
通过发出
git blame HEAD -- path/to/file如果更改尚未提交
git blame HEAD~1 -- path/to/file如果更改已经完成
然后，在这两种情况下，我都使用 git log <COMMIT 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手册页，但是我没有找到一个合适的选项来实现这一点（我确信我可能遗漏了一些东西）。
是的，我也试过在网上搜索这个。但是，嗯，我花了一页的时间来描述它-我应该如何制定黄金谷歌搜索表达式来找到这个？
是的，你将在下一节看到，我有自己的想法。
我的方法
我将创建一个脚本来解析由 git log -p或 git diff生成的补丁。
它将使用“我想知道什么”部分中的规则输出修补程序影响的所有行号。
然后bash脚本通过检查 git blame HEAD[~1]输出来查找提交id，并提取提交id。
最后一步是获取提交消息。
另一个步骤是，用刚刚找到的提交消息装饰整个补丁输出（多个块和文件）。
（实际上，目前我正在编写一个python脚本来进行补丁解析）
替代方法
也许这可以通过从 git blame -- <FILE>和 git blame HEAD -- <FILE>中提取commit列并将两个输出都输入到 diff中，然后为 grep -C <N>设置 00000000来找到受影响的commit id来实现。
但我认为这是脆弱的，不如上述方法可靠。我也需要分析一下责任的差异。
（我已经试过了。最困难的部分是diff输出解析。）
试着把它简化成一个问题。
是否有一个标准的git工具，通过显示提交（通过应用提交更改的位置）将git的错误与git日志提供的数据结合起来？
我希望我的问题足够清楚。：）
保持安全。
我确定，我是。

Answer 1

为了帮助完成后一部分，您应该真正研究git rebase -i --autosquash。autosquash rebase将查找特殊格式的提交，以便在重新定位时自动对提交进行重新排序，并将其标记为压缩/修复。从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）相同的行，但是您不希望您的提交（a）与（b）合并，而是与旧的（c）合并，那么您很容易意外地挤压错误的提交。
通常情况下，您希望合并到的提交与当前更改没有冲突的编辑，因此没有任何魔力可以使脚本预言您想要做的事情。因此，编写这一部分的脚本是微不足道的，相反，我发现使用基于gui的历史浏览器极大地帮助了这一步（我在linux上使用gitg，在mac上使用gitx，但任何历史浏览器都可以做到）。