仅仅为了创建 CI 测试的集成分支而进行分支和合并是一个好主意吗？
鉴于我们或多或少使用 GIT 的分支工作流程 http:// nvie.com/posts/a-successful-git-branching-model/ 按照此流程定期使用 Jenkins 等 CI 工具进行集成测试是否有意义。
- 创建一个新分支只是为了日常集成测试，从开发分支合并
- 所有计划用于下一个版本的功能分支（如果我们将它们全部命名为 Sprint-#-feature 那么我们可以通过名称前缀选择分支并自动合并）到这个特殊分支
- 在这个新分支上运行 CI 集成测试
- 删除分支
我的理论是，通过这样做，我们可以通过多种方式避免可怕的合并问题。首先，自动合并可能无法让我们知道白天做了一些事情来将我们移出简单的合并区域。其次，我们得到的集成测试结果与我们当时决定将所有内容合并到版本中时所得到的结果相同。显然，这确实取决于开发人员在 CI 构建开始之前每天清理功能分支上的工作并推动掌握，但这似乎并不是一个真正繁重的要求。由于我们放弃了合并，这意味着开发人员在正式合并到开发分支之前仍然有机会清理他们的提交历史记录。
有人尝试过这种事情吗？你会用不同的方式来做吗？
我实际上只是在寻找一种利用自动化进行更多测试和更频繁测试的方法。编写单元测试和 TDD 并不能真正解决集成测试的这一领域，因为您通常会运行额外的集成测试，而不仅仅是单元测试和 TDD 测试。
Given that we are using GIT with more or less the branching workflow of http://nvie.com/posts/a-successful-git-branching-model/ does it make sense to regularly do integration testing with a CI tool like Jenkins by following this process.
- Create a new branch just for the daily integration test, branching from develop
- Merge all feature branches scheduled for the next release (if we name them all Sprint-#-feature then we can select branches by name prefix and auto merge) into this special branch
- Run CI integration tests on this new branch
- Delete the branch
My theory is that by doing this we can avoid scary merge problems in a couple of ways. First of all an auto merge could fail letting us know that during the day something was done to move us out of simple merge territory. Secondly, we get the results of the same kind of integration tests that we would have had if we had decided to merge everything into a release at that point in time. Obviously this does depend on developers cleaning up their work on feature branches and pushing to master every day before the CI build starts but that doesn't seem like a really onerous requirement. Since we throw away the merge this means that a developer still has a chance to clean up their commit history before they do the official merge into the development branch.
Has anyone tried this kind of thing? Would you do it in a different way?
I'm really just looking for a way to leverage automation to do more testing and more frequent testing. Writing unit tests and TDD doesn't really address this area of integration tests because you would generally run additional tests for integration, not just the unittests and TDD tests.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您实际上可以获得您提到的所有好处，再加上一项。
git 的
rerere扩展将记录您对合并冲突的手动解决方案，因此，如果您在自动合并失败时手动执行日常集成分支合并，那么您最终的“真正”合并将会更容易（并且您可以利用这一点使每个离散的损坏成为一次性的事情，因为下一次自动合并将会成功）。唯一的缺点是混乱：很难跟踪哪些变化出现在哪里。小心不要忘记集成分支中不存在的内容......
但是，原则是合理的。
You actually get all the benefits you mention, plus one.
The
rerereextension to git will record your manual resolutions of merge conflicts, so if you do that daily integration branch-merge by hand when the automatic merger fails, your final "real" merge will be easier (and you can leverage this to make each discrete breakage be a one-time thing, since the next automerge will succeed).The only down side is confusion: it can be difficult to track which changes are present where. Be careful not to forget what's not present in the integration branch...
But yes, the principles are sound.
我们改进了您网站的分支模型。看看这里：
http://dymitruk.com/blog/2012 /02/05/branch-per-feature/
您需要将 dev 和 RC 分支视为 CI 以两种不同方式使用的废弃分支。 rerere 对这个工作流程有很大帮助。您也可以与同事分享 rerere。使用 master 分支来标记已发布到生产环境的内容。让您的 CI 服务器标记成功构建。
希望这能让你开始。请随时联系我了解更多信息。
We improved on the branching model you site. Have a look here:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
You need to think of dev and RC branches as throw away branches that are used by CI in 2 different ways. rerere helps a lot in this workflow. You can share rerere with your coworkers too. Use the master branch to mark what was released to production. Have your CI server tag successful builds.
Hope that gets you started. Feel free to ping me for more info.