关于源代码管理的最佳实践是什么？
关于源代码管理的最佳实践是什么？
提问于 2009-06-03 14:24:47
我们是在ERP系统上工作的不同地理位置的软件开发人员团队。我们使用SVN作为版本控制系统。在代码移动到生产系统之前，我们有4个环境。
我想知道在这种情况下使用SVN时，关于分支和合并的最佳实践是什么。
目前，我们面临一个问题，一个文件有4个更改。客户只希望在X版本中有2个更改(每年4个主版本和4个次要版本)。
我们面临的问题是:分支太多。复杂的手动合并。丢失跟踪或更改覆盖其他人的代码。
有没有人可以说，如何使用SVN作为更好的工具来解决这个问题，它确实是这样。
Kedar Hukeri，谢谢和问候。
Stack Overflow用户
发布于 2009-06-03 15:37:08
您所要求的是统一的变更管理，而这正是Subversion并没有真正设计好的(IMO)。这将需要一些手动工作来管理更改。但假设你有合适的问题跟踪系统，下面是我工作过的许多地方做过的事情：
main branch (trunk) - new feature development here
|- release-1.0 - locked release branch
|--- release-sp1
|--- release-patches - patch release fix stream (new fixes merged here)
|------ release-sp1-issue# - this is where you make your bug fixes
before merging them.
This issue# is the bug-id in your tracking system.一旦修复了错误并提交到补丁发布，您就可以删除旧的-issue#分支。这可以防止分支失控，但可以让您保持较小的变更集。
可以通过使发布主干只对集成者可写来强制维护人员。通过apache：Subversion/Apache Permissions使用subversion，您可以创建一个组、集成者，并在项目上设置以下权限
project
|- branches (everyone: rw)
|- individual-fixes
|- release-branches: (integrator: rw, everyone: ro)
|- release-1.0-fixes
|- release-2.0-fixes
|- trunk (integrator: rw, everyone: ro) <- new dev goes here!!!!
|- tags (integrator: rw, everyone: ro)
|- release-1.0
|- release-1.0-sp1
|- release-2.0 然后每个合并都是小的，很好地跟踪，并且只有一小部分人可以进行合并。然而，这给您的合并团队带来了瓶颈。我从来没有与大型git/mercurial团队合作过，以了解这是如何工作的。
您也可以实现类似的功能修复，但要在主干上实现。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/945068
复制相关文章
相似问题
腾讯云开发者
