如何使用 SVN 管理源代码？分支、合并
我们是由 4 名位于不同地点的开发人员/朋友组成的团队。我们都已经开始处理 ProjectX 并使用 Subversion 创建了分支 A、B、C 和 D。
我们只有源代码版本控制的基本知识。有一天，我们中的一个人试图将分支 A 与 B、C 合并，而 D 和 B 则尝试与 A、C 和 D 合并。（他们甚至不知道如何合并它：D，只需右键单击 > 合并） > 合并一系列修订）我们遇到了一些冲突，并解决了它们。再次尝试合并，再次右键单击......）再次冲突。
现在所有的代码都被搞乱了。我们有 4 个不同的代码副本（D 缺少 B 的功能，但有 C 的功能等）。所以我在这里浏览了很多关于SO的帖子，阅读了SVN书籍，特别是这个文章（如何正确分支）对于理解如何合并分支和主干有很大帮助。我想我对未来有了更好的理解。但我该如何摆脱目前的困境呢？
我的问题是：
- 由于我们 4 个人正在从事同一个项目，但通常从事不同的工作，我们应该只有一个分支吗？然后创建4个工作副本，然后仅提交和更新。一旦我们准备好合并主干到分支，分支到主干？根据上述文章中的建议
- ，您可以建议任何工作吗-这样我们就可以将 4 个分支发送到主干，然后我可以进行导出以再次从头开始版本控制。
- 另外我认为如果再次使用 4 个分支，我们每个人都应该每天/定期更新我们的分支并从主干获取更改（合并）并将本地更改合并回主干吗？ （而不是尝试合并分支到分支:-D）
请建议我们应该使用什么工作流程？这样维护代码的痛苦就最小了。谢谢。
We are team of 4 developers/friends located in different locations. We all have started working on the a ProjectX and created branches A, B, C and D using Subversion.
we have just basic knowledge of version controlling the source code. Other day one of us just tried to merge Branch A with B,C, and D and B tried to merge with A, C, and D. (and they didnt even know how to merge it :D, just right click > merge > merge a range of revisions) We got some conflicts, solved them. Tried merging again, again right click .....) Conflicts again.
Now that all of the code has been messed up. we are having 4 different code copies (D missing B's functionality but having C's etc etc). So I went through lots of threads here on SO, read the SVN book and especially this article (how to branch properly) helped a lot in understanding how to merge branches and trunk. I think I have got a better understanding for the future. But how do I get out of current situation??
My questions are:
- As 4 of us are working on same project but usually work on different bits, should we just have one branch?? and then create 4 working copies and then commit and update only. Once we are ready merge trunk to branch, branch to trunk? as per suggestion in the above article
- Can you please suggest any work-flow so that we can get our 4 branches to the trunk and then I can take an export to start the version controlling from scratch again.
- Also I think if go again with 4 branches, should each of us daily/regularly update our branch and get changes from trunk (merge) and merge local changes back to trunk?? (instead of trying mergin branch to branch :-D)
Please suggest what work flow we should use? so that its a minimum pain in maintaining code. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我不会为每个开发人员创建一个分支。我推荐一个持续集成流程，其中你们四个人都从一个“主干”中签出并合并频繁更改 - 每天多次。理想情况下，您将拥有一个标准化的构建工具（例如 Maven、Ant 等）和一个构建调度程序（例如 Hudson、Cruise、TeamCity 等）。在 SCM 工具 (Subversion) 之上拥有这两个工具，您可以有一个流程不断构建您签入主干的所有更改，并在出现问题时向所有开发人员发送电子邮件。这可以防止您因错误的更改或合并而破坏构建，同时允许您保持轻量级分支结构（即一个分支 - 主干）。
分支使得将您的代码更改与您的队友的代码更改集成起来更加困难。分支确实应该用于分支——创建软件的专门管理的“分支”。例如，如果您要发布软件的 1.0 版本，那么在主干上创建一个 1.0 分支可能是个好主意（在开发之后但在发布之前），这样您就可以在不影响正在进行的版本的情况下维护该版本。 trunk 上的开发（可能是 2.0 版本）。
我建议使用使用 Subversion 进行实用版本控制。这是对 SCM 的相当全面的概述，其中包含 Subversion 的详细信息。
I would not create a branch per developer. I recommend a continuous integration process where all four of you check out from a single "trunk" and merge changes frequently - many times per day. Ideally you would have a standardized build tool (e.g. Maven, Ant, etc.) and a build scheduler (e.g. Hudson, Cruise, TeamCity, etc.). Having these two tools on top of your SCM tool (Subversion) you can have a process continuously building all changes you check into the trunk and emailing all developers whenever there is a problem. This protects you from breaking the build through bad changes or merges while allowing you to keep a light-weight branching structure (i.e. one branch - the trunk).
Branches make it more difficult to integrate your code changes with that of your teammates. Branches should really be used for, well, branching - creating specially managed "branches" of your software. For example, if you are releasing version 1.0 of your software, it would probably be a good idea to create a 1.0 branch off of the trunk (after development but before releasing) so you have a place to maintain this version without impacting on-going development on the trunk (perhaps for version 2.0).
I recommend grabbing Pragmatic Version Control with Subversion. It's a pretty solid overview of SCM with specifics for Subversion.
还有另一个借口发布 Eric Sink 的 源代码控制指南 的链接。
这无疑是我发现的关于源代码控制的最佳介绍，并且无论您使用什么工具，它都是相关的。
And another excuse to post a link to Eric Sink's source control howto.
This is far and away the best introduction to source control I've found and is relevant regardless of the tools you use.
最安全的策略是为每个CR（更改请求/任务/错误/等）创建一个分支。
流程如下：
通过CMT（变更管理工具，如 Bugzilla）向开发人员提供 CR；
CR 已分析。如果它有意义，它就会被接受，并且开发人员会为其创建一个分支。分支名称可能类似于：
projectName_crNumber_crCreationDate_developerId
工作完成（测试、提交等）后，开发人员应该锁定分支，这样就没有人会更改它，将 CR 标记为已解决（在 CR 处通知分支名称） ），并等待CM（配置管理器）将其合并到构建分支（以及其他开发分支）；
当一定数量的CR合并到一个构建分支（build_xxx）后，应该对这个集成版本进行测试。如果一切正常，那么它应该被合并到卡车上。
每当主干实现某个目标/里程碑（CR 集）时，就可以应用标签。
很多细节都被省略了。这是具有高质量标准的大型团队采用的工作流程。对于小团体来说，它可能不够灵活。然而，大多数任务都可以使用现有工具实现自动化和安排。
The safest strategy is to create a branch for each CR (Change Request / Task / Bug / etc).
The flow would be like this:
A CR is given to a developer through a CMT (Change Management Tool, like Bugzilla);
The CR is analyzed. If it makes sence it is accepted and the developer creates a branch for it. The branch name could be something like:
projectName_crNumber_crCreationDate_developerId
After the work is done (tested, commited, etc), the developer should lock the branch, so no one would change it, mark the CR as resolved (inform branch name at CR), and wait to the CM (Configuration Manager) to merge it to a build branch (along with other development branches);
After a certain number of CRs are merged into a build branch (build_xxx), this integrated version should be tested. If everything is OK it should then be merged to the truck.
A label could be applied each time the trunk achieves a certain goal/milestone (set of CRs).
Lots of details have been omitted. This is a workflow adopted by large teams with high quality standards. It may not be flexible enough to small groups. However, most of this tasks can be automated and scheduled with existing tools.
通常，只有 4 个人在编写代码，因此不需要 4 个分支。您可能根本不需要分支，只需将所有内容放入一个主干中并进行处理即可。将您签出的本地工作副本视为您的“匿名本地分支”。
如果您预计代码在一段时间内至少存在两个版本，则分支很有用。例如，当您发布版本 2.0 时，您希望开始开发 2.1，但在可预见的将来必须支持 2.0。您可以将 2.1 作为一个全新的项目启动，但随后您将失去将修复程序从 2.0 移植到 2.1 的能力，反之亦然。因此，您命名一个版本主干并从中分支。
另一种情况是，当你们中的一个人开始实现一个新模块或重新实现一个现有模块时，并且知道这将需要一段时间（比通常的提交周期更长），并且不能保证在此期间不会影响其他人的代码时间。然后你让他分支，开发他的东西，然后你想出如何将它合并回去。在这里，您再次有一个主干，您可以从中分支并合并回来。
Normally, with only 4 guys working on the code you don't need 4 branches. You probably don't need branches at all, just put it all into one trunk and work on that. Think of your checked out local working copy as your "anonymous local branch".
Branches are useful if you anticipate your code to exist in at least two versions for a certain time. For example, when you release version 2.0, and you want to start working on 2.1 but have to support 2.0 for the forseeable future. You could start 2.1 as a whole new project, but then you'd lose the ability to port fixes from 2.0 to 2.1 and vice versa. So you name one version trunk and branch from it.
Another scenario is when one of you starts implementing a new module or reimplementing an existing module, and knows it's going to take a while (longer than your usual commit cycle) and can't guarantee that it's not going to affect other people's code during that time. Then you let him branch, develop his thing, and then you figure out how to merge it back. Here again, you have one trunk you branch from and merge back to.
一般来说，如果你们都在开发软件的不同部分，您会发现在同一个分支中工作是最简单的。如果您通常不处理相同的源文件或相互依赖的软件部分，那么您不会发现在更新工作副本时经常出现冲突，也不会在提交时发现损坏的源树。
SVN 中的分支（相对于分布式修订控制系统）更适合于进行大的、彻底的更改，这些更改可能会破坏同事的代码或需要大量工作（在这种情况下，您想要进行许多增量提交，这可能会导致您的系统崩溃）。不编译）或诸如管理版本之类的事情。
使用单个分支（主干，如其他答案中指出的）。当多个人必须处理相同的代码时，那么第二个检查的人将手动解决冲突。修复一个修订版中的冲突比尝试将更改的多个修订版合并到另一个分支（该分支在拆分后也推进了多个修订版）要容易得多。
Generally, if you're all working on different pieces of the software, you'll find it easiest to work out of the same branch. If you're not commonly working on the same source files or on parts of the software that depend on each other, you won't find you frequently have conflicts when you update your working copies or a broken source tree when you commit.
Branches in SVN (as opposed to a distributed revision control system) are more intended for big, sweeping changes that are likely to either break your colleagues' code or require a lot of work (in which case you want to make many incremental commits that may not compile) or things like managing releases.
Go with a single branch (the trunk, as pointed out in other answers). When multiple people have to work on the same code, then whoever checks in second will fix the conflicts by hand. Fixing conflicts in one revision is much easier than trying to merge several revisions of changes into another branch that also has advanced several revisions since they split.
如果您仅限于 SVN，请继续阅读，如果没有，您听起来像是 DVCS 如 Mercurial、Git 或 Bazaar。
对于 SVN，根据我过去的经验，通常最好保留所有内容合并到的主干（参见示例 此处）。每个人都应该合并回主干，然后从主干合并到分支。在 SVN 中从一个分支合并到另一个分支似乎是一个坏主意。
If you are restricted to SVN, keep reading, if not, you sound like a prime candidate for DVCS like Mercurial, Git, or Bazaar.
For SVN, from my past experience it is generally best to keep the trunk where everything is merged into (See examples here). Each person should merge back into the trunk and then you merge from trunk to your branch. Merging from branch to branch in SVN seems like a bad idea.