git version 1.8.1.4
gcc (GCC) 4.7.2
您好，
我使用git作为我的respostery，每次都需要添加新功能或需要修复的bug。我从最稳定的分支创建一个新分支，然后我继续添加新功能或修复bug。通常，我可以同时处理许多新功能和错误修复。所以我可以有很多git分支。
这会与测试人员产生冲突，因为他们不想测试新功能或错误修复。他们希望我做的是在完成它们之后将所有内容合并到稳定分支中，然后一次性测试所有内容。这对测试人员来说是好事，因为他们只测试一次。
然而，我希望他们做什么：
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 .
这意味着测试人员必须测试更多，他们不喜欢这样做。
问题是，在测试之前将所有内容合并在一起会产生更多错误。因为我将一个未经测试的分支合并为一个稳定的分支。如果我将一些分支合并到一个稳定的分支中，这可能会导致稳定分支出现更多错误。
问题：
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?
非常感谢任何建议，
答案 0 :(得分：1)
两种论点都没有绝对的对错。就个人而言，我会采取一些中间立场（并在其他地方做了类似的测试要求）。我会将最稳定的分支分支到一个主题分支（features_and_fixes，或其他类似的聪明的东西）。为每个新功能或错误分支 分支。这有一个好处，一开始可能看起来不太清楚。您正在分享所有个人功能和修复的共同基础。这应该会使合并更改变得更加容易。
一旦您测试了每个单独的功能或修复（因为我假设您的测试人员确实是验证者并且您彻底测试了自己的代码），那么您可以合并回公共主题分支。合并每个新功能或修补程序后再次测试更改，修复与找到它们相关的合并相关错误。
一旦一切都好，那么你可以将整个粉碎合并到原来的稳定分支中。如果合并导致问题，一个提交会将您带回到您开始的位置。这对您来说意味着更多的测试（因为您必须两次测试自己的代码），但您也可以快速安全地合并任意数量的更改。你是一个可以撤消大量变化引起的混乱的人。我就是这样......