Question

我以前有过使用git的经验但是是Subversion的新手。我的任务是为我的团队建立一个存储库，但不确定最佳结构应该如何。（建议我回到git赢得在这里工作，因为我几乎坚持颠覆，但我感谢你的诚实建议！）

假设我的团队中有三个开发人员（Sam，Tom，Bob），他们每个人都需要自己的分支进行开发（他们会委托自己的分支机构，以便他们可以跟踪自己的更改和修订。我看看这是一个解决方案，因为subversion没有像Git那样的本地提交功能。在subversion中提交相当于在Git中推送。）。之后，他们将他们的更改推送到测试然后生产。这是我想到的结构：

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

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

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

问题：
1.这是颠覆团队项目的良好结构吗？ 2.是否有可能指出开发人员的根源？分支到测试分支？因此，当单击VisualSVN / Update时，开发人员分支将自动更新到测试分支的头部。

Answer 1

只是（混乱）思考

在/trunk MyProject是过多的节点（仅因为存储库专门用于MyProject）
在per-developer + stable（trunk）| unstable（Test）分支中，你会得到很多合并（因此 - 可以随时成为“Merge Hell”的受害者：你可以尽量避免上下文冲突，但在开发分支之间的双向合并期间的树冲突会等待你）
“End-day Nightmare”（从测试合并到Test + merge）将需要强大的纪律和注意力以及准确性（及时间）
对于短期任务（单独提交）“共享分支”可能会更好
“每个任务分支”代替“每个开发者分支”提供更易理解的存储库树和可管理的开发+发布（具有短期分支，与任务相关，PM | TL可以随时监控状态 - 与之比较“永远”开发者的分支机构）。但它不会（绝不）禁止对任何WIP使用个人“货架”
而不是使用中间测试分支进行同步开发人员可能希望尝试按需使用直接跨分支合并（但无论如何请参阅第2页）

为团队合作设置Subversion

1 个答案: