在Git中使用测试分支

我们有一个人（我们叫他Ted）负责测试新功能和错误修复。

我们正在使用Git和GitHub。master应该/始终可以部署，并且development是我们提交/合并新功能或错误修复的地方，但前提是经过Ted测试之后。

该项目使用PHP。

我希望测试过程如下：

1. 开发人员想要开发新功能（例如，问题跟踪程序中Ted记录的功能/错误＃123），因此他origin/development进入development了自己的本地存储库，并issue-123从那里创建了一个新分支（比如）。
2. 对工作感到满意后，他承诺并将其新分支推至origin。
3. Ted连接到test.ourproject.com/choose-branch并看到分支上的列表，origin然后选择打开issue-123（应该可以通过网页进行操作）。然后test.ourproject.com，他继续进行测试，在Web应用程序之外进行测试（他真的很无情），在与开发人员反复交流之后，他对该功能感到满意。
4. 特德告诉他可以合并开发issue-123到development上origin。
5. 冲洗并重复。

第三步，我可以破解一些可以完成工作的东西（显示和切换特定页面上的分支），但是我觉得我所描述的是非常普遍的模式。

所以我的问题是： 这是分支的良好/可持续/可维护的工作流程吗？您是否可以通过引用此工作流程中其他项目的一些示例来备份您的答案？

分支工作流程听起来很像gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow，周围有支持工具。强烈建议。

如果只有一名测试人员，则您的测试工作流程听起来不错，但是如果有多个人员，则开发可能会在开始和结束之间进行，当然，理想情况下，在合并之后应完全执行测试。这是自动测试真正可以提供帮助的地方，或者缓慢（彻底）的测试人员可能永远无法完成！

另一个问题是，对于许多功能和分支，它们倾向于将功能混合并匹配到一个发行版中（或选择在接受和合并后退出），或者如果功能相互依赖。问题是，如果您开始尝试重写已发布分支上的历史记录（重新定位/删除提交或合并），这意味着该分支已被推送到multidev存储库中。这是重写公共历史。它可以是好事，也可以是邪恶的，即使做得好也可能给粗心大意的人带来问题，而最佳实践是避免这样做，这样就永远不会出现问题。但是，某些集成分支工作流非常诱人，因此，如果您在此类分支上拥有强大的保护能力（例如，每个用户的gitolite分支限制），并且人们期望此类活动，那么请始终将其代码重新建立在此类分支上，请谨慎操作！

我还建议阅读http://sethrobertson.github.com/GitBestPractices/，该书讨论了所有这些问题，并有很多很好的参考。

我不确定切换页面本身是否是常见模式。大多数项目可能只是让测试人员使用git命令将其签出。

一般的方法肯定听起来很合理。

谷歌甚至写了Gerrit来支持类似的风格。它更多地是关于审查代码，但批准集成通常涉及审查和测试。通常，它还与持续集成服务器互连，后者首先构建所有提交内容（我不确定他们是否在Google中使用Jenkins，但我相信我在某处看到了合适的连接器）。

Git本身在主题上使用了一些细微的变化。它的维护者拥有一个脚本，该脚本将所有待处理的提交合并到一个分支中pu（大概是“建议的更新”；由于经常要更改待处理的提交，因此每次都删除并重新创建该分支）。这是经过各种人的检验。如果可以的话，然后将被认为已完成的提交合并到next（与您的相同development）。如果不是，那么有人会测试各个提交的内容，以查看哪个被破坏了。这使测试人员的工作变得容易一些，因为他们通常不必切换分支。他们只是报告测试集成是否有效。

如果您的测试是自动完成的，而不是手动完成的，那么我认为Travis（GitHub的CI系统）将做您想要的一切-它会自动对所有请求请求运行测试。（有关此过程的更多信息，包括屏幕截图。）

请注意，测试不在分支上运行，而是在合并到master之后的分支上运行。（即，将分支合并到master中后会得到什么-您可以确保测试在合并后仍然可以成功运行。）

如果将提交添加到分支，则重新运行测试。（尽管出于某种原因，向主服务器添加提交似乎并没有重新运行测试。）