`git commit --amend` 是否触及了不必要的文件？

Question

我经常遇到以下情况：

1. 修改文件 A、B 和 C。
2. 使用git commit 提交修改。
3. 构建项目，因此构建是最新的。
4. 仅对文件 A 进行后续/修复修改。
5. 运行git commit -a --amend（或git commit --amend path/to/A）
6. 逐步重建项目。

现在，由于自上次构建以来我只修改了文件 A，我希望只有文件 A 被重建，但我总是看到 A、B 和 C 的所有内容（即，整个提交所涉及的所有文件）都被重建。

在我看来 git commit --amend 它 touching / 碰撞 A、B 和 C 中每一个的最后修改时间戳，即使我只是在提交中添加了 A 的修改。

有必要吗？是否可以避免，只触及A，只重建A？

如果重要的话，我的项目是 C++ 并且我的构建系统是 cmake+ninja，但我认为这在很大程度上是多余的，因为构建系统依赖上次修改的时间戳来确定要重建的内容是相当标准的。

Answer 1

git commit 不会触及您工作树中的任何文件。这里用--amend没关系。

没有-a 的git commit 也不会使用您的工作树中的任何文件，但git commit -a 具有Git，实际上，首先运行git add -u，这将从工作树中>读取一些文件，以便将它们复制到索引中。然后，不管有没有-a，git commit 都会从索引中的任何内容构建新的提交。

新的提交一旦完成，就会有一些新的、唯一的、从未见过的哈希 ID。如果你正在做一个普通的git commit（没有--amend），你的存储库中有一些系列的提交，每个都有自己唯一的哈希ID，last这样的提交有一些哈希身份证H：

... <-F <-G <-H   <-- your-branch (HEAD)

（这里，大写字母代表实际的原始哈希 ID，它们看起来是随机的，但实际上并非如此，但也无法预测。）新提交获取其新的唯一哈希 ID I，并且在I 中，存储的父哈希ID 为H。 Git 将新 ID 写入分支名称，给出：

...--F--G--H--I   <-- your-branch (HEAD)

使用--amend，不同之处在于，不是让新提交I 指向现有提交H，而是使用H 具有的相同 父级构造新提交，在这种情况下为G。效果是H 被推到一边：

          H
         /
...--F--G--I   <-- your-branch (HEAD)

现有的提交 H 没有改变，但它似乎消失了：从 I 开始并向后工作无法找到它。所以git log 隐藏它，它似乎消失了，好像 Git 以某种方式改变了 H。 Git 没有； H 仍然完好无损。默认情况下，它仍然可以恢复至少 30 天，因为哈希 ID 存储在 Git 所谓的 reflogs 中。但它看起来不见了。

如果您看到各种文件被重建，这并不是因为 Git 本身接触了源文件。其他东西可能触及了源文件，或者——我的猜测，但只是一个猜测——你的构建系统可能会将它们标记为依赖于特定的 Git 提交哈希：因为 I 的哈希与 H 不同，并且构建工件是 H 而不是 I 的结果，它们现在已经过时了。

（当然，其他可能性包括更改文件时间戳的 Git 挂钩。）

Answer 2

避免这种情况的一种方法（手动）是在不修改的情况下进行所有提交，当您完成更改后，rebase interactively 压缩提交（您现在正在修改的那些）