Question

我有以下情况：有时在树下我创建了一个有效的测试文件。在树的某个地方，测试破了，但我没有抓住它。我想去那个地方，并修复该测试文件，然后继续使用该新测试文件重新测试后续提交（例如，使用git bisect或其他方式）。我怎么能这样做？

* tuvw1 (master)
|
* oprs2
|
* xyzw3 - testfile broke here and needs to be updated hereon, onwards
|
* mnop4
|
* abcd5 - test file  first added

在我看来，理想的答案是能够将固定的测试文件无缝地合并到提交＃3，＃2，＃1中，以便我可以使用像git bisect这样的工具。

但我会接受任何合理的答案，这将允许我测试我的分支从＃3开始到掌握新测试，即使有点手动找到一个新的突破点（因为提交3和1我的测试再次中断）。在我的例子中只有3次提交，这可能没有问题，但我的实际数字更像是破解的测试提交和主提交之间的20次提交。

可能的解决方案

我认为“理想”的答案是简单地在主人之上进行新提交，修复我的文件。然后，在我的提交＃3上使用git rebase，然后只需按照我想要的方式重新提交提交。问题当然是我将重写树的那一部分，而我现有的标签将在旧树上，而不是新树。我需要重新创建这些标签。此外，当我push --force新树来源时，它会搞乱其他开发人员的git树。当然，它可以通过一些规划和沟通来解决，但由于这些提到的问题，很可能它不是一个很好的解决方案。

换句话说，我可能只需要手动测试，或者如果需要捕获各种测试错误，请使用我的本地树进行测试。如果除了手动之外有更好的方法来做到这一点，那么这就是我想知道的答案

Answer 1

rebase为时已晚，没关系。你不能总是在你的树中有无错误的代码，希望你下次会做得更好。因此，您将完全像修复代码时那样提交“修复测试用例”。
话虽如此，您仍然可以在另一个分支上重新设置代码，使用git-bisect自动化等等，最终拥有更好，更清洁的树。但是，您不应更新标记或push --force此分支。这个分支非常适合记录您如何解决测试问题。

最后，您的主分支可以合并这个临时分支，以便将所有修复程序带到实际分支。例如：

 ---o---A--B--C--D-------------------o--(master)
     \                              /
      \---A'--X--B'--Y--C'--(fix)--/

Answer 2

你可以

git config filter.pin-content.clean 'git show HEAD:%f 2>&- || cat'
git config filter.pin-content.smudge 'cat %f 2>&- || cat' 
echo 'your/patterns filter=pin-content' >> .git/info/attributes

并且内容不会更改（git add运行“干净”过滤器，这一个忽略了工作树，支持已经提交的内容; git checkout运行“涂抹”过滤器，这个忽略承诺的内容，而不是工作树中的任何内容。

如何使git在git树中回溯使用更新的文件

2 个答案: