我们在交付新版本时的政策是在我们的VCS中创建一个分支并将其处理给我们的QA团队.当后者发出绿灯时,我们会标记并发布我们的产品.分支保持接收(仅)错误修复,以便我们可以创建技术版本.这些错误修复随后合并在主干上.
在此期间,主干会看到主要的开发工作,并且可能会受到重构更改.
问题是需要有一个稳定的主干之间存在紧张关系(以便错误修复的合并成功 - 如果代码已被提取到另一个方法,或者移动到另一个类,通常不能)在引入新功能时需要重构它.
我们的政策是在经过足够的时间之前不进行任何重构,并且分支足够稳定.在这种情况下,可以开始对主干进行重构更改,并在主干和分支上手动提交错误修复.
但这意味着开发人员必须等待一段时间才能在主干上进行任何重构更改,因为这可能会破坏从分支到主干的后续合并.并且必须手动将分支中的错误移植到主干上是很痛苦的.在我看来,这妨碍了发展......
你怎么处理这种紧张局势？
谢谢.
我是颠覆的新手,我想知道你如何从发展转向分期再生产？
我想我已经掌握了为发布创建分支的概念,详见此处.但是我如何实际部署分支？
理想情况下,我可以设置一个新的网站并从分支复制文件,但我担心将任何svn绑定复制到生产中.
如果它是相关的,这是一个Visual Studio网站项目,我使用VisualSVN服务器,TortoiseSVN和Ankh与Visual Studio集成.
我现在只是在Agile进行一些正式的培训,我遇到的一个问题是关于持续构建的价值与经常提交到版本控制系统的价值.
我对版本控制的理解是经常提交它更好,因为那时你有历史和能够以细粒度的方式回到以前的变化.
我对敏捷和持续构建的理解是,它会给开发人员施加压力,使他们始终拥有工作代码.打破源树是一个禁忌的事情.
现在我同意这两种观点,但有时候这些观点可能会相互影响.您可能正处于较大的代码更改过程中,并希望提交代码以确保您具有历史记录,但这会破坏源代码树.
有没有人对此有任何想法？
我与一个中型开发人员团队一起工作，他们都在开发一种产品。开发人员编写代码以解决功能或错误修复程序，然后将其检入我们的主要开发分支（在Subversion中）。一旦质量检查人员对票证进行了测试和验证，我便将其合并到行李箱中。我通常手动执行此操作，因为许多故障单跨越了多个修订版本，这些修订版本并不总是顺序的，并且可能一次包含多个故障单的修复。
我确定会帮助开发人员在每个修订版中只签入一张票。我们使用Jira来跟踪任务，因此每个Subversion修订版在日志中都应有一个Jira问题ID-当我合并代码时，我会寻找包含我要合并的问题的修订版。
还有其他方法可以更好地解决这个问题吗？其他团队是否会为每张票和票都从行李箱分支出来？正如我所说，我们有一个主要的开发分支，至少部分是因为我们正在迅速构建许多新功能，而且我想如果为每张票证制作一个分支，很快就会有数十个分支。