建立团队合作的颠覆

Question

我以前有过git的经验，但我是个颠覆的新手。我的任务是为我的团队建立一个存储库，但不确定如何才是最好的结构。(建议我回到git不会在这里工作，因为我被颠覆困住了，但我很感激你诚实的建议！)

假设我有三个开发人员(Sam、Tom、Bob)在我的团队中，他们每个人都需要自己的分支来进行开发(他们致力于自己的分支，这样他们就可以跟踪自己的更改和修订。我认为这是一种解决办法，因为subversion不像Git那样具有本地提交功能。在subversion中提交等同于在Git中推送。)在此之后，他们将更改推送到测试然后生产。以下是我想要的结构：

MyProject
   /trunk
         /MyProject
   /branches
         /Test
         /Sam
         /Tom
         /Bob
   /tags

工作流程如下:在一天结束时(或白天)，所有开发人员都会从测试分支中提取更改，然后将更改推送到测试分支，并在需要时解决冲突。对于生产更新，主干中的将与测试分支合并。

让我们假设开发人员定期地将他们的更改推送到测试分支，这样合并的尝试不会导致灾难性的冲突。

问题：

1. 对于subversion团队项目，这是一个很好的结构吗？
2. 是否可以将开发人员分支的根指向测试分支？因此，当单击VisualSVN/Update时，开发人员分支将自动更新到测试分支的头。

Answer 1

Just (混沌)思考

• 在/trunk中，MyProject是过多的节点(仅仅是因为存储库只用于MyProject)
• 在每个开发人员+稳定(主干)不稳定(测试)分支中，您将得到许多合并(因此--可以在任何时候成为“合并地狱”的牺牲品:您可以尝试避免上下文冲突，但是在开发分支之间双向合并期间的树冲突在等待您)
• “终日噩梦”(合并为测试+从测试合并)将需要很强的纪律、注意力和准确性(和时间)。
• 对于短期任务(单独提交)，“共享分支”可能会更好。
• “每个任务分支”而不是“每个开发人员分支”给出了更容易理解的存储库树和可管理的development+release (带有与任务相关的短期分支，PM\\TL可以随时监视状态--将其与“永久”开发人员的分支进行比较)。但是它不会禁止在任何WIP上使用个人的“书架”。
• 与使用中间测试分支进行同步不同，开发人员可能想尝试按需使用直接的跨分支合并(但无论如何见第2页)。