每个bugfix的分离分支与dev分支的嫁接

我有3个环境 - dev，stage和production的应用程序。我有很多功能/错误修正必须独立部署到舞台和制作。每个bugfix的分离分支与dev分支的嫁接

的错误修正和功能通常有2/3的提交。

目前我使用水银为我的项目，但我不能决定哪个方向走。最好的应该是使用命名分支，但我不知道它是正确的1/2/3内提交。我发现移植物看起来也很有前景。

所以我的问题是如何版本的文件，如果我需要单独能够部署的变化？

2014-07-27 deem

您应该只从“主”或主分支部署到生产。每个错误修复/功能通常都是它自己的分支，以便您可以独立验证行为而不影响主分支。一旦确定修复或功能完成，应该将其合并回主分支。从这个意义上说，您应该使用嫁接，其目的是从备用分支（即您的错误修复分支）中选择接受的更改回到主分支进行部署。你不能在没有分支的情况下使用嫁接，分支是测试对源代码库进行修改的最合适的方法，所以你不要用无意义或虚假的提交混乱主分支。您的主分支应该能够随时部署并仍然正常工作。

来源

2014-07-27 06:59:32 sfdcfox

这是也有可能有一个舞台分支，并从开发移植到舞台。 –

@SteveBarnes是的，我认为是一样的，但我不知道一个错误修复的分离分支将是一个更好的选择。 – deem

@deem您可以从任何分支移植到任何其他分支。您的错误修正可以全部存在于他们自己的分支中，最终移植到分段，最后移植到主/主分支。保持每个错误修复或功能在其自己的分支上，可以让您对分支进行不同的分析，以查看修复中涉及的文件/行，并且您可以轻松地仅从diff/patches中撤消某个分支。我现在工作的团队现在只使用分支来标记发布，但我认为隔离修复将是更好的选择。它可以让你避开半固定的错误等。 – sfdcfox

您可以使用任何水银分支模型（名为|匿名分支机构，书签，克隆） - 它的口味和习惯和任务的更多问题 - 与名为分支，你就可以容易在未来的（如果|在需要时）检测与每个完成的WIP作业相关的部分回购历史记录（仅仅因为唯一的分支名称是每个变更集中的永久性元数据，与匿名/共享相同的名称与父/分支或书签驱动/历史记录相反共同分支与其他变更/历史分支混合）。

命名分支密集使用的单缺点是hg branches输出长一段时间后。我更喜欢使用命名的分支，只是因为它给的变化和更精致的日志可恢复历史：而不是重复与嫁接变更的变化我看到一个合并的完成任务的库显示图形的每一个积分都合并的目标

来源

2014-07-27 13:15:43

您知道在大约5k分支时可以有多大.hg /目录吗？我读Mercurial可以处理甚至Nk分支，但它是否对克隆，合并，更新（最新变更集）命令有任何性能影响？看来git拥有更好的这种项目管理方式的架构。我还发现了类似http://www.plasticscm.com/features.aspx的东西，这些东西是专门为任务开发设计的，每个功能/错误修正应该是一个分离的分支。 – deem

@deem - 不，我不知道大小。是的，一大批**分支机构可以并且将会影响整体绩效，但经过数年的发展后，它将会非常显着**，并且可以通过按年龄拆分知识库来解决 –

每个bugfix的分离分支与dev分支的嫁接

回答

相关问题