我知道另一个SVN指南问题。
我最近加入了一家新公司，该公司拥有一些网站。我们有一些开发人员和图形设计师，我们所有人都使用SVN。我们每个人都有个人工作副本和沙箱可供使用，并将所有东西都提交到行李箱。
以下是我们面临的问题：
有时，多个ppl会处理相同的功能/错误（例如我和图形人员）。为了让我们同步我们的工作（例如，让我看到新的图片/ css），图形人需要提交他的更改，我必须更新我的工作副本。因此，在一天结束时，我们对从trunk到RC分支的合并进行了大量修改。
通常我们被要求实现一个功能，好的，完成后，将代码提交到trunk。然后我们被要求修复一个错误（修复这个错误它以某种方式使用为该功能编写的一些代码，并且没有人记住它）好的，错误修复，测试，提交错误修复到主干。搞砸了部分后来我们被告知我们不会发布该功能但需要发布错误修复。
还有一些场景，但我现在不记得了。你们认为哪些改变会改善我们的流程？
此致
詹姆斯
答案 0 :(得分：2)
这可能是将svn更改为某些分布式svc（如mercurial或git）的好时机。我没有使用它们，但根据我所读到的内容，它们在合并和分支方面的摩擦力较小，这似乎是问题所在。
答案 1 :(得分：2)
我们的商店是这样的...
行李箱只是生产中的物品
如果开发人员需要创建更改，他会从主干创建一个分支。在分支等处执行他的更改...
在部署分支之前，从主干到分支进行合并。这样你就可以在分支中进行主干+最新的更改
一旦分支机构部署到生产阶段并进行了一些测试，那么刚投入生产的分支机构就会重新集成到卡车中。
没有人接触到主干，除了部署后的小窗口外，它始终是生产的工作快照。
答案 2 :(得分：2)
您可以拥有自己和图形人员工作的功能分支。确保你已经写出了你们两个都会做的任务，以及什么时候你们两个之间肯定存在一些依赖关系（正如你们似乎正在经历的那样）。
我们的团队使用设计师的一个好方法是我们坐下来并迅速制定了一个'API'或基本代码合同，他可以在开发人员编写代码的同时设计它。
尝试将两者经常集成到您的分支和主干。如果检查中存在大的间隙，则合并变得更加困难（代码漂移）。合并工具只能让你到目前为止。
错误确实在功能完成后发生，没有人是完美的，但确保你有一个正确的错误跟踪系统，并将错误分配给最佳人选（通常是最了解该功能的人）。
如果你有一个人知道这个功能并且他去度假，你可以得到团队中没有其他人知道它是如何工作的情况。在这种情况下，我发现最好尽可能地分享团队周围的知识。如果你使用敏捷对等（对）编程可以工作，也许代码审查。
记住沟通是大型项目的关键，只需向下一个人了解手头的任务，就可以分享知识和理解。
HTH