git - merge 和测试的最佳实践，我们应该测试更多吗？

Question

git version 1.8.1.4
gcc (GCC) 4.7.2

你好，

我使用 git 作为我的资源库，每次有需要添加的新功能或需要修复的错误时。我从我们最稳定的分支创建一个新分支，然后继续添加新功能或修复错误。通常，我可以同时处理许多新功能和错误修复。所以我可以有很多 git 分支。

这会与测试人员产生冲突，因为他们不想测试新功能或错误修复。他们希望我做的是在我完成后将所有内容 merge 到稳定分支中，然后他们一次性测试所有内容。这对测试人员有好处，因为他们只测试一次。

但是，我希望他们做什么:

1) Test the new feature or bug fix on that branch.
2) Once it has passed I will merge it to the stable branch.
3) Once is has been merged into the stable branch test it again to make sure it still works .

这意味着测试人员必须进行更多测试，而他们不喜欢这样做。

问题是，在测试之前将所有内容 merge 在一起会产生更多错误。因为我将把一个未经测试的分支 merge 到一个稳定的分支中。如果我将几个分支 merge 到一个稳定的分支中，这可能会导致稳定的分支有更多错误。

问题:

1) I am just wondering is my concept correct or are the testers correct?
2) Is there any offical or standard document that I can use to show them that everything should be tested first before merging?

非常感谢您的任何建议，

Answer 1

这两种说法都没有绝对的对错。就个人而言，我会采取一些中间立场(并且在其他具有类似测试要求的地方也这样做过)。我会将最稳定的分支分支到主题分支(features_and_fixes，或其他类似的聪明分支)。为每个单独的新功能或错误从那个分支分支。这有一个好处，一开始可能不太清楚。您正在从所有个人功能和修复程序的共同基础上分支。这应该会使 merge 更改变得非常非常容易。

一旦您测试了每个单独的功能或修复(因为我假设您的测试人员确实是验证者并且您彻底测试了自己的代码)，那么您可以 merge 回公共(public)主题分支。 merge 每个新功能或修复后再次测试您的更改，并在发现时修复与 merge 相关的错误。

一旦一切顺利，就可以将整个 smash merge 到原来的稳定分支中。如果 merge 导致问题，一次提交会让您回到起点。这将意味着对您进行更多测试(因为您必须对自己的代码进行两次测试)，但您也将能够快速安全地 merge 几乎任意数量的更改。你离消除大量变化造成的任何困惑只有一步之遥。这就是我想要的......