我正在谷歌上搜索一下，找不到SVN的好“初学者”指南，而不是“我如何使用命令”的意思;如何控制源代码？
我想澄清的是以下主题：
我不知道分支和标签是什么，所以我不知道目的，但我猜测是你将内容上传到主干，当你做一个主要的构建时，你将它移动到分支？那么，在这种情况下，什么被视为主要构建？
答案 0 :(得分：86)
当我们在这里实施Subversion时，我问自己同样的问题 - 大约20个开发人员分布在4-6个项目中。我没有找到任何一个有“答案”的好消息来源。以下是我们的答案在过去3年中如何发展的一些部分：
- 尽可能经常提交;我们的经验法则是，只要您完成了足够的工作就会提交，如果修改丢失，则必须重新执行此操作;有时候我每15分钟左右一次，有时候可能是几天（是的，有时我需要一天时间来写一行代码）
- 我们使用分支，作为您之前提出的建议之一，用于不同的开发路径;现在，对于我们的一个程序，我们有3个活动分支：1个用于主要开发，1个用于尚未完成的程序并行化，1个用于修改它以使用XML输入和输出文件; < / p>
- 我们几乎不使用标签，但我们认为我们应该使用它们来识别生产中的版本;
考虑沿着单一路径进行开发。在开发营销的某个时间或状态决定发布产品的第一个版本，因此您在标记为“1”（或“1.0”或您拥有的）的路径中设置标记。在某些其他时间，一些明亮的火花决定将程序并行化，但决定这需要数周时间，并且人们希望在此期间继续沿着主要道路走下去。所以你在路径上建立一个分叉，不同的人在不同的叉子上徘徊。
道路上的旗帜称为“标签”，道路上的叉子是“分支”划分的地方。有时，分支也会一起回来。
- 我们将构建可执行文件（或系统）所需的所有材料放入存储库;这至少意味着源代码和make文件（或Visual Studio的项目文件）。但是当我们有图标和配置文件以及所有其他东西时，它会进入存储库。一些文档进入了回购路径;当然，任何文档，例如可能是程序不可或缺的帮助文件，都是放置开发人员文档的有用位置。
我们甚至为我们的生产版本提供Windows可执行文件，为寻找软件的人提供单一位置 - 我们的Linux版本将发送到服务器，因此不需要存储。
- 我们不要求存储库始终能够提供构建和执行的最新版本;有些项目是这样工作的，有些则没有;该决定取决于项目经理，取决于许多因素，但我认为在对计划进行重大更改时会出现问题。
答案 1 :(得分：60)
subversion book是有关布置存储库，分支和标记的策略的绝佳信息来源。
另见：
答案 2 :(得分：18)
* How often do you commit? As often as one would press ctrl + s?
尽可能经常。代码不存在，除非它受源代码控制：）
频繁提交（此后较小的更改集）允许您轻松集成您的更改并增加不破坏某些内容的机会。
其他人注意到，当你有一段功能代码时你应该提交，但是我发现稍微提交一些代码很有用。很少有人注意到我使用源代码控制作为快速撤消/重做机制。
当我在自己的分支上工作时，我更愿意尽可能多地提交（就像我按ctrl + s一样）。
* What is a Branch and what is a Tag and how do you control them?
阅读SVN book - 这是学习SVN时应该开始的地方：
* What goes into the SVN?
文档，构建所需的小二进制文件以及其他具有一定价值的东西都可以用于源代码控制。
答案 3 :(得分：11)
以下是有关提交频率，提交消息，项目结构，源代码管理内容以及其他一般准则的一些资源：
这些Stack Overflow问题还包含一些可能感兴趣的有用信息：
关于基本的Subversion概念，例如分支和标记，我认为在the Subversion book中已经很好地解释了这一点。
正如您在阅读了有关该主题的更多内容后可能会意识到的那样，人们对该领域最佳实践的看法往往是变化的，有时甚至是相互矛盾的。我认为最适合您的方法是阅读其他人正在做的事情，并选择您认为对您最有意义的指导方针和做法。
如果您不了解其目的或不同意其背后的理由，我认为采用某种做法并不是一个好主意。因此，不要盲目地遵循任何建议，而是要对自己认为最适合自己的事情做出自己的想法。此外，尝试不同的做事方式是学习和了解你最喜欢工作方式的好方法。一个很好的例子就是你如何构建存储库。没有正确或错误的方法，在实际尝试之前，通常很难知道您喜欢哪种方式。
答案 4 :(得分：8)
提交频率取决于您的项目管理风格。如果它会破坏构建（或功能），很多人都会拒绝承诺。
分支可以通过以下两种方式之一使用：通常：1）一个用于开发的活动分支（并且主干保持稳定），或者2）用于备用dev路径的分支。
标签通常用于识别版本，因此它们不会在混合中丢失。 “发布”的定义取决于您。
答案 5 :(得分：6)
我认为主要问题是源控制的心理图像是混淆的。我们通常有主干和分支，但是后来我们得到了关于标签/发布的不相关的想法或者那些影响的东西。
如果你更彻底地使用树的想法，它会变得更清晰，至少对我来说是这样。
我们得到主干 - ＆gt;形成分支 - ＆gt;生产水果（标签/释放）。
这个想法是你从一个主干增长项目，然后在主干足够稳定以保持分支时创建分支。然后当分支产生一个水果时，你从分支中取出它并将其作为标记释放。
标签本质上是可交付成果。而树干和树枝则产生它们。
答案 6 :(得分：4)
正如其他人所说的那样，SVN Book是最好的起点，一旦你掌握了大腿，它就是一个很好的参考。现在，问你的问题......
你多久犯下一次？经常会按ctrl + s？
通常，但不像按ctrl + s那样频繁。这是个人品味和/或团队政策的问题。就个人而言，当你完成一段功能代码时我会说提交，无论多么小。
什么是分支，什么是标记？如何控制它们？
首先，trunk是您进行积极开发的地方。它是您的代码的主线。分支与主线有一些偏差。这可能是一个重大的偏差，就像之前的版本一样，或者只是一个你想尝试的小调整。标记是代码的快照。这是一种将标签或书签附加到特定修订版的方法。
值得一提的是，在颠覆中，主干，分支和标签只是惯例。没有什么能阻止您在标签中工作或拥有作为主线的分支，或者忽略tag-branch-trunk方案。但是，除非你有充分的理由，否则最好坚持使用惯例。
进入SVN的是什么？只有源代码或您在此处共享其他文件吗？
也是个人或团队的选择。我更喜欢在我的存储库中保留与构建相关的任何内容。这包括配置文件，构建脚本，相关媒体文件，文档等。您应该不签入每个开发人员的计算机上需要不同的文件。您也不需要检查代码的副产品。我主要考虑构建文件夹，目标文件等。
答案 7 :(得分：4)
（Eric是SourceGear的创始人，他推销了SourceSafe的插件兼容版本，但没有可怕的。）
答案 8 :(得分：4)
只是添加另一组答案：
答案 9 :(得分：3)
其他人表示这取决于你的风格。
最重要的问题是你经常“整合”你的软件。测试驱动的开发，敏捷和Scrum（以及许多其他）依赖于小的变化和持续的集成。他们鼓励做出微小的改变，每个人都会找到休息时间并一直修复它们。
然而，对于一个更大的项目（想想政府，国防，100k + LOC），你根本无法使用持续集成，因为它是不可能的。在这些情况下，使用分支进行大量的小提交可能会更好，但只能将后端带回到主干中，并且可以将其集成到构建中。
但有一点需要注意的是，如果它们管理得不好，它们可能会成为你的存储库中的噩梦，因为每个人都是从主干上的不同位置开发的（这是偶然的一个持续整合的最大论据。）这个问题没有明确的答案，最好的方法是与您的团队合作，提出最佳的妥协解决方案。
答案 10 :(得分：2)
Version Control with Subversion是初学者和老手的指南。
我认为如果不至少阅读本章的前几章，就不能有效地使用Subversion。
答案 11 :(得分：1)
对于提交，我使用以下策略：
尽可能多地提交。
每个功能更改/错误修复都应该得到自己的提交（不要一次提交多个文件，因为这会使该文件的历史记录不清楚 - 例如，如果我单独更改日志记录模块和GUI模块，我立刻同时提交，两个文件历史记录中都会显示这两个更改。这使得阅读文件历史很困难），
不要破坏任何提交的构建 - 应该可以检索任何版本的存储库并构建它。
构建和运行应用程序所需的所有文件都应该是SVN。测试文件等不应该，除非它们是单元测试的一部分。
答案 12 :(得分：1)
这里有很多好的评论，但没有提到的是提交消息。这些应该是强制性和有意义的。特别是分支/合并。这将允许您跟踪哪些更改与哪些错误功能相关。
例如svn commit . -m 'bug #201 fixed y2k bug in code'会告诉任何查看历史记录的人。
某些错误跟踪系统（例如trac）可以在存储库中查找这些消息并将它们与故障单相关联。这使得很容易计算出与每张票相关的变化。
答案 13 :(得分：1)
我们工作的政策就是这样（开发面向对象框架的多开发团队）：
每天从SVN更新以获得前一天的更改
每天提交，如果您第二天生病或缺席，其他人可以轻易地从您离开的地方接管。
不要提交破坏任何内容的代码，因为这会影响其他开发人员。
处理小块并每天提交有意义的评论！
作为一个团队：保留一个开发分支，然后将预发布代码（用于QA）移动到生产分支。这个分支应该只有完整的代码。
答案 14 :(得分：0)
TortoiseSVN TSVN Manual基于subversion book，但有更多语言版本。
答案 15 :(得分：0)
我认为提交频率有两种方式：
我更喜欢第一个 - 因为使用源代码控制系统不仅对项目或公司非常有用，首先它对开发人员有用。对我来说，最好的功能是在搜索最佳分配的任务实现时回滚所有代码。