|
|
4 回复 | 直到 7 年前
|
1
2
如果您希望工作不能按时完成,并且您没有足够的测试体来进行持续集成,那么分支是很方便的。我倾向于在编程任务太大而无法预期完成的商店中看到疯狂的分支开发,因此管理层希望等到发布之前确定应该发布哪些功能。如果你正在做这样的工作,那么你可能会考虑使用分布式版本控制,其中每个工作目录都是一个自然分支,你可以得到所有的本地签入和本地历史记录,你可以在不伤害任何人的情况下吃。您甚至可以与主干之外的其他开发人员交叉合并。 我的偏好是,当我们在一个不稳定的主干中工作时,分支用于发布候选,然后标记为发布,然后成为紧急补丁的流。在这样的系统中,您很少有超过三个分支(最新版本、当前候选版本、不稳定主干)。如果您正在执行TDD,并且在不稳定的主干上有CI,则此方法有效。如果您需要分解所有任务,以便可以根据需要随时交付代码(通常一个任务应该只有一到两天,并且可以在没有构成其功能的所有其他任务的情况下发布)。因此,程序员承担工作,检查主干,完成工作,同步并在任何时候通过所有测试。不稳定的主干始终可以作为发布候选分支使用(如果所有测试都通过),因此发布将成为非事件。 总的来说,更好的方法是:更少的分支,更短的任务,更短的发布时间,更多的测试。 |
|
2
1
一个明显的想法是更“重设基础”(更频繁地从“父”环境阶段合并回“子”环境“开发”到开发分支),以最小化主干的最终影响->DEV,这将不再需要了。 也就是说,任何在阶段中完成的、必须一次性投入生产的(主干)都应该尽早在DEV和privatedevs分支中合并,否则那些后期的改装合并总是一件痛苦的事情。
但是,如果上面的合并工作流程太不方便的话,我建议在发布(新主干)之后,基于最新的开发版本,创建一个REBASE分支。重基主干->DEV将成为TRUNK->在所有问题都已解决的情况下重新设置基础,然后进行最终合并开发->重新设置基础,以检查任何当前开发人员是否与新更新的系统兼容。最后一次从REBASE到DEV(以及到私有DEV分支)的简单合并将完成该过程。
|
|
3
1
|
|
|
4
0
对我们来说,所有的发展都发生在一个分支中。我们针对每个bug和每个特性进行分支。理想情况下,该分支只用于一个特性,但有时并不打算这样做。 当工作完成、测试并“准备好”时,我们将更改合并到主干中。我们的规则是,主干在任何时候都不应该破坏其中的代码。如果断开的代码进入主干,修复它就成了首要任务。 当所有功能都完成并合并时,将进行发布:发布的分支将作为标记创建。标签允许我们在需要时检索shapshot。分支机构允许我们提供以前版本的支持。修复发布版本中的bug是通过转到该版本的分支,从该分支进行分支来完成的。当一切正常时,更改会合并回发行版的分支,如果需要,会一直合并到主干。 |
