0

我以前有 git 的经验,但是是 Subversion 的新手。我的任务是为我的团队建立一个存储库,但不确定最好的结构应该是怎样的。(建议我回到 git 在这里不起作用,因为我几乎被颠覆所困,但我感谢你的诚实建议!)

假设我的团队中有三个开发人员(Sam、Tom、Bob),他们每个人都需要自己的分支进行开发(并且他们提交到自己的分支,以便他们可以跟踪自己的更改和修订。我认为这是subversion 没有像 Git 那样的本地提交功能的解决方法。在 subversion 中提交相当于在 Git 中推送。)。之后,他们将更改推送到测试然后生产。这是我想到的结构:

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

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

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

问题:
1. 这是颠覆团队项目的良好结构吗?
2. 是否可以将开发者分支的根指向测试分支?所以当点击VisualSVN/Update时,开发者分支会自动更新到测试分支的头部。

4

1 回答 1

0

只是(混乱的)思考

  • MyProject中/trunk的节点过多(只是因为存储库专门用于 MyProject)
  • 在 per-developer+stable(trunk)|unstable(Test) 分支中,您将获得很多合并(因此 - 随时可能成为“Merge Hell”的受害者:您可以尝试避免上下文冲突,但树冲突期间开发分支之间的双向合并等着你)
  • “末日噩梦”(合并到测试+从测试合并)将需要强大的纪律、注意力和准确性(和时间)
  • 对于短期任务(单独提交),“共享分支”可能会更好
  • “Branch Per Task”而不是“Branch Per Developer”提供了更易于理解的存储库树和可管理的开发+发布(具有短期分支,与任务相关,PM|TL 可以随时监控状态 - 将其与“forever”进行比较开发商的分支机构)。但它不会(绝不能)禁止将个人“货架”用于任何 WIP
  • 而不是使用中间测试分支来同步开发人员可能想要尝试按需使用直接跨分支合并(但无论如何请参见第 2 页)
于 2014-06-17T10:22:40.537 回答