SVN介绍

Question

我正在与使用SVN的其他开发人员合作。我是SVN的新手，我想更好地了解如何最好地使用SVN。

我们现在有：

                            __ branch developer 1
Project 1                 /___ branch developer 2
      |                  /____ branch developer 3
      |____ branches---- \____ branch developer 4
      |                   \___ branch developer 5
      |____ tags           \__ branch developer 6
      |
      |____ trunk

在开始发展之前，他们问我：

1. 更新我的分支
2. 从其他分支合并我的分支并解决冲突，所以我必须从dev1，dev2，dev3等合并... 承诺我的作品

现在，我的问题是......这是正确的approch？每次都需要花费很多时间才能完成这么多合并。或者我们应该只为所有开发人员使用一个分支？我是SVN的新人，我不想做错事......所以我真的很感谢你帮我把它放到正确的路上。

Answer 1

不，这不是使用SVN的正确方法。每个开发人员都没有理由拥有自己的分支机构。

通常，每个人都在后备箱上工作。如果某些功能很难开发并且不能在主干上完成以避免干扰其他开发人员，则会创建一个特定的功能分支。从主干的更改定期合并到此功能分支，一旦功能完全在其自己的功能分支中开发，分支将重新集成到主干中，并被删除。

如果每个人都必须不断地从其他人的分支中进行合并，那么与在主干上工作一样没有什么不同，除非它更加痛苦。并且它无论如何都不会扩展到超过2或3个开发人员。

我建议您阅读免费提供的SVN book，其中详细解释了上述所有内容，并与您的同事讨论，使其采用传统的最佳做法。

Answer 2

我个人认为上面的当前实施是疯了。目前有7个分支（每个开发人员一个），每个分支需要七个合并才能开始任何工作。

只要有更多的开发人员加入团队，合并策略就变得异常繁琐，容易出现更多错误。在您甚至可以自己开始开发之前，您可能需要编辑X个分支中的冲突。

我会让每个开发人员都在存储库的主干上工作。在处理一个repo目录时，更容易管理冲突解决和合并。

理想情况下，您希望在敏捷工作流程（小型可管理的大块工作）中工作，最多只需要几天即可完成。任何比这更长的项目都可能值得拥有自己的分支文件夹，纯粹是为了将代码与主干的大量重构分开，以免破坏团队其他成员的工作流程。

完成大型任务后，您只需要将一个分支文件夹合并回主干（由于其工作已经完成，其他开发人员不断更新）。

应该使用源代码管理系统来简化开发工作流程，而不是更复杂。

Answer 3

我同意其他人的说法，你的策略目前是疯了！ ;）

就个人而言，我更喜欢将主干保持为稳定的“实时”版本，并将所有开发保留在一个分支中，这样所有开发人员都可以在同一个分支上工作，只需要在您的功能或项目时进行合并准备好上线了，你知道自从你分支后主干没有改变。

虽然上面的选项可行，但我担心每次主干上发生更改时都必须不断更新分支，并且增加了冲突的可能性（如果主干是实时代码，则会损坏网站/产品）。 / p>

Answer 4

像其他答案一样告诉你：这种方法只是脑死亡。在你最终完成工作之前，你会浪费你的时间从不同的分支合并。

除此之外：如果您想为每个开发人员分配内容，为什么不使用分布式VCS，如mercurial或Git？

如果您必须学习SVN（并且尚未被宠坏），您也可以学习mercurial或Git。并且有good reasons可以切换。

我两年前为Git放弃了SVN，并且没有一天后悔。相反，我喜欢便宜的分支，工作合并，在他们进入主人之前的返工提交以及所有这些。

每个人都在本地工作，当涉及将事物合并回master（在SVN中称为trunk）时，开发者合并然后推送到中央回购。你不必浪费任何关于哪个开发人员应该在哪个分支上工作的想法。

关于分支，这里有一篇非常受欢迎的文章一个成功的Git分支模型：http://nvie.com/posts/a-successful-git-branching-model/

也许你可以说服你的同事，转换对他们的工作来说是一个真正的好处。我正在使用一个坚持手动合并的人，即使我们正在使用Git。每周需要2到3个小时来同步我们的工作。只有两个人的工作。如果你要从更多的东西中进行合并，那么更多的时间可以更好地使用。