我最近开始了一份新工作，到目前为止他们只有一名开发人员。将Eclipse和Collabnet与Subversion一起使用。 所以，他在冲突等方面没有任何问题。 更是如此，因为它是对原始应用程序的完全重写，因此不会与任何其他代码发生冲突。
这也使他能够随时提出（以防他的电脑“死”），没有任何问题。
SVN目录是在没有主干的情况下构建的。一切都直接在根目录中。
我们现在有3名开发人员。我仍然希望他们能够每天提交，但不要干扰他人的工作。 所以，我认为现在正确的方法是为每个开发人员创建一个主干然后单独的分支。这是对的吗？
如果是，那么进行此更改的最简单方法是什么。我看到这个链接，但它已经很老了，我想知道是否有一种新的，更简单的方法。 Is there a clean way to move / to /trunk?
答案 0 :(得分：2)
经常提交和更新。
除非正在编写/编辑不同的代码部分，否则必须发生冲突。遇到冲突越早（因此它们越小）越好。每天承诺还不够。
理想情况下，提交应该是原子变化。最小的可能变化，在保持稳定性和正确性的同时增加了代码。换句话说，如果您添加3个不同的功能然后提交，则提交可能不够小。每个功能都应该有自己的提交。 （或者，如果任何功能不小，可能不止一次提交。）
理想情况下，您还应该尝试沟通将要进行的更改。它在实践中的工作效果差异很大，但是如果你知道程序员A今天将在模块X上工作，那么除非必要，否则避免修改模块X代码可能是个好主意。
至于移动根，据我所知，这确实仍然是推荐的方法。只做一次就不是什么大不了的事。
编辑：我应该提一下，我绝不是一个svn工作流专家。我使用git工作了大约6个月的4人团队，以及使用svn几年的2人团队。这篇文章是根据我注意到的，随着时间的推移帮助或伤害我们的事情。
答案 1 :(得分：1)
您的日常工作不应该是分支。让每个人都在主源目录中的文件上工作。将代码移动到子目录（例如“/ trunk”）可能很聪明，这样您也可以在根目录中拥有其他目录（例如，分支目录）。
发展时会发生冲突，但它们应该很小并且很容易解决。提交应尽可能小。 TortoiseSVN具有良好的用户界面，可在您提交时解决冲突。
必须使用分支的唯一时间是两个或更多开发人员在无法提交到主干的功能上协同工作，例如，如果它未准备好在即将发布的时候发布发布并计划在以后发布。
创建分支的好时机是您发布应用程序时。为第一个版本创建一个名为1.X的分支。然后继续朝着主干中的2.0工作。在1.X分支中，您可以构建1.0版本，以及稍后版本1.1等等（不会干扰主干中的2.0工作）。
请注意这两种分支之间的区别：发布分支从主干分叉并永远存在。可以在主干和发布分支之间合并各个错误修正，但是发布分支永远不会合并回主干。
在功能分支中，通过合并连续导入主干更改。功能完成后，整个分支将合并到主干中，之后不会使用分支。
Release branches __testing_1.X__..._rel_1.0___.._rel_1.1 ___2.X_branch_
/ /
___________trunk__________/_______trunk______________________________/____..
\ /
\_____really big feature for v2 only__________/
Feature branches
对于日常开发，您可以根据需要使用分支。一个选项是每个功能一个分支，但您可能会发现这会产生比解决小团队更多的问题。解决SVN中的冲突通常比管理多个分支和执行许多合并要容易得多。在其他版本控制系统（例如Git）中，情况有所不同。