是否可以将提交相互绑定以使它们在平分、樱桃选择、还原等方面具有原子性？-解网

问：

考虑一个错误修复的情况，它会导致预期输出发生微小变化，从而迫使测试套件中发生微小的变化。在同一提交中同时进行两个更改非常方便，因为它可以使审阅者清楚地了解输出中更改的内容。另一方面，有时您可能只想查看源的差异，或预期输出的差异，如果提交是分开的，则更容易做到这一点。此外，这两件事在逻辑上是不同的，因此进行不同的提交是有意义的。

我希望能够进行两个不同的提交，但以某种方式将两个提交链接在一起（这样我就可以将两个提交作为一个原子单元进行挑选、还原等）。此外，如果进行了两次不同的提交，那么测试套件将在第一次提交时失败（除非引入第三次提交以放宽测试套件），从而使未来的一分为二变得痛苦。未来平分法失败的问题通常会鼓励我进行一次提交，但提交应该是逻辑上不同的单元，并且对代码的提交在逻辑上与对测试套件中预期输出的提交不同。

有没有办法进行两个不同的提交，而不必向后弯腰以防止二分在其中一个上失败？（例如，必须明确提及要跳过的提交）

Git 工作流

问题正在演变......动机是这样一种情况，即两行代码更改导致数百行预期输出略有更改，并且由于测试中的更改量，代码更改被埋没在差异中。我想要一种简单的方法来查看代码差异。此外，如果每次提交只影响一个文件，通常更容易，但像这样进行提交组会破坏构建并导致平分失败。感觉工作流程是错误的，而且提交不够细化。

答：

5赞 VonC 6/3/2011 #1

明确地将这些更改（代码和单元测试）保留为一个提交：SCM 还涉及能够重现给定状态，包括程序及其测试。

如果您只需要查看代码更改，请执行 git diff only on 而不是 on 。
由于这些链接的更改保留在一次提交中，因此可以完全避免平分问题。srctst

简而言之，保持简单;)

但 git 不仅仅是一个 SCM。它是用于构建更改集的工具。我认为这些更改在逻辑上是不同的（我们可以谈论“代码更改”和“测试更改”这一事实证明了这一点），因此保持它们的不同是有意义的，但最佳实践（在每次提交时保持树可构建）与更改的逻辑独特性相冲突。在这种情况下，感觉就像我们在扭曲我们的工作流程以匹配工具，而不是制作工具以匹配工作流程。

0赞 VonC 6/4/2011

@William：是的，基本上不要试图过多地扭曲工具;)代码更改和单元测试更改的一次提交就足够了。

0赞 Tyler 6/6/2011

“我认为这些变化在逻辑上是不同的（我们可以谈论”代码更改“和”测试更改“这一事实证明了这一点）” -- 我们也可以将“foo.c 中的更改和 bar.c 中的更改”作为单独的更改来讨论，即使它们在同一个提交中。我们甚至可以讨论同一文件的两个不同部分的更改，即使它们在同一个提交中。重要的是，在这两种情况下，这两个“不同的更改”都是“修复错误 X”的单个“更改”的一部分，因此它们属于同一个提交。

0赞 VonC 6/6/2011

@MatrixFrog：我不反对你的分析，这似乎强化了我的答案。我不明白为什么这个答案刚刚被否决了。

0赞 Tyler 6/6/2011

是的，我同意你的回答（我投了赞成票）。我的评论更多的是对威廉的评论的回应，而不是对你的回答的回应。我应该更清楚这一点。

0赞 Adam Dymitruk 6/3/2011 #2

如果您愿意，可以将它们保存在开发分支中的单独提交中。在每对提交后，合并到功能分支中。这应该使您能够以任何一种方式执行操作。

是否可以将提交相互绑定以使它们在平分、樱桃选择、还原等方面具有原子性？

Is it possible to bind commits to each other to make them atomic in terms of bisect, cherry-pick, revert, etc?

评论

评论

评论