分支和合并仅仅是为CI测试创建集成分支是一个好主意吗？

Question

鉴于我们使用GIT或多或少使用http://nvie.com/posts/a-successful-git-branching-model/的分支工作流程，通过遵循此流程定期对像Jenkins这样的CI工具进行集成测试是有意义的。

1. 为日常集成测试创建一个新分支，从develop
分支
2. 合并为下一个版本安排的所有功能分支（如果我们将它们全部命名为Sprint - ＃ - feature，我们可以通过名称前缀和自动合并选择分支）到这个特殊分支中
3. 在此新分支上运行CI集成测试
4. 删除分支

我的理论是，通过这样做，我们可以通过几种方式避免可怕的合并问题。首先，自动合并可能会失败让我们知道在白天做了一些事情来使我们离开简单的合并领域。其次，如果我们决定在那个时间段将所有内容合并到一个版本中，我们将得到相同类型的集成测试的结果。显然，这确实取决于开发人员在CI构建开始之前每天清理他们在功能分支上的工作并推动掌握，但这似乎并不是一个非常繁重的要求。由于我们抛弃了合并，这意味着开发人员仍然有机会在他们正式合并到开发分支之前清理他们的提交历史。

有没有人尝试过这种事情？你会以不同的方式做到吗？

我真的只是在寻找一种利用自动化来进行更多测试和更频繁测试的方法。编写单元测试和TDD并没有真正解决这个集成测试领域，因为你通常会进行额外的集成测试，而不仅仅是单元测试和TDD测试。

Answer 1

你实际上得到了你提到的所有好处，加上一个。

git的rerere扩展名将记录您的合并冲突的手动解决方案，因此如果您在自动合并失败时手动执行每日集成分支合并，那么您的最终“真正”合并将更容易（并且你可以利用这个来使每个离散的破坏成为一次性的事情，因为下一次的automerge会成功）。

唯一的缺点是混乱：很难跟踪哪些变化存在于哪里。小心不要忘记集成分支中没有的内容......

但是，原则是合理的。

Answer 2

我们改进了您网站的分支模型。看看这里：

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

您需要将dev和RC分支视为以两种不同方式丢弃CI所使用的分支。 rerere在此工作流程中提供了很多帮助。您也可以与同事分享rerere。使用master分支标记发布到生产的内容。让您的CI服务器标记成功构建。

希望能让你开始。请随时与我联系以获取更多信息。