我到处搜寻了一下，找不到SVN的良好“入门”指南，而不是“我如何使用命令”的意思。如何控制我的源代码？
我要清除的是以下主题：
我不知道什么是分支和标签，所以我不知道目的，但我的猜测是您将内容上传到主干，并且在进行大型构建时将其移动到分支？那么，在这种情况下，什么被视为主要构建？
Answers:
当我们在这里实施Subversion时，我问过自己同样的问题-大约20个开发人员分布在4-6个项目中。我找不到“答案”的任何好来源。以下是过去三年来我们的答案如何发展的部分内容：
-尽可能多地提交; 我们的经验法则是，只要您做了足够的工作，便会提交，如果修改丢失，将不得不重新进行操作；有时我每15分钟左右提交一次，其他时候可能是几天（是的，有时我需要一天才能编写一行代码）
-我们将分支机构（作为您较早提出的建议之一）用于不同的开发路径；现在，对于我们的程序之一，我们有3个活动分支：1个用于主要开发，1个用于尚未完成的并行化程序，1个用于修改以使用XML输入和输出文件的工作。
-我们几乎不使用标签，尽管我们认为应该使用标签来标识生产版本；
想一想发展的方向。市场有时会决定发布产品的第一个版本，因此您可以在标记为“ 1”（或“ 1.0”或您拥有的产品）的路径中标记一个标志。在另一些时候，一些聪明的决定决定使程序并行化，但是决定这将需要数周时间，并且人们希望与此同时继续走上主要道路。因此，您在路径上构建了一个分叉，并且不同的人在不同的分叉之间徘徊。
道路上的标志称为“标签”，道路上的叉子为“分支”的分隔位置。有时，分支也会重新聚集在一起。
-我们将构建可执行文件（或系统）所需的所有材料都放入了存储库中；这意味着至少要有源代码和make文件（或Visual Studio的项目文件）。但是，当我们有图标和配置文件以及所有其他内容时，它就进入了存储库。一些文档进入了仓库。当然，程序中可能包含的任何文档（例如帮助文件）都可以，并且这是放置开发人员文档的有用位置。
我们甚至将生产版本的Windows可执行文件放在此处，为寻找软件的人们提供一个单一的位置-我们的Linux版本可以存储在服务器上，因此无需存储。
-我们不要求存储库始终能够提供可生成和执行的最新版本；有些项目以这种方式工作，有些则没有；该决定取决于项目经理，并且取决于许多因素，但是我认为在对程序进行重大更改时该决定会失败。
* 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书籍 -学习SVN时应该从这里开始：
* What goes into the SVN?
文档，构建所需的小二进制文件和其他有价值的东西都归源控制。
以下是有关提交频率，提交消息，项目结构，要置于源代码控制之下的内容以及其他一般准则的一些资源：
这些堆栈溢出问题还包含一些可能有用的有用信息：
关于诸如分支和标记之类的基本Subversion概念，我认为这在Subversion书中已得到很好的解释。
您可能会在阅读了更多有关该主题的知识后意识到，人们对于该领域最佳实践的看法经常各不相同，甚至有时会发生冲突。我认为对您来说最好的选择是阅读别人在做什么，并选择您认为最有意义的准则和做法。
如果您不了解实践的目的或不同意其背后的原理，那么我认为采用该实践不是一个好主意。因此，不要盲目听从任何建议，而要对自己认为最适合自己的东西下定决心。同样，尝试不同的做事方式也是学习和发现自己最喜欢工作的好方法。一个很好的例子是如何构造存储库。这样做没有对与错的方法，通常很难在实践中真正尝试过它们之前就知道您更喜欢哪种方法。
提交频率取决于您的项目管理风格。如果它破坏了构建（或功能），许多人不会提交。
分支可以以两种方式之一使用，通常是：1）一个用于开发的活动分支（并且主干保持稳定），或2）用于备用开发路径的分支。
标签通常用于标识发布，因此它们不会在组合中丢失。“发布”的定义由您决定。
就像其他人所说的，SVN书是最好的起点，并且一旦您获得了成功，便是一个很好的参考。现在，对您的问题...
您多久提交一次？尽可能多地按ctrl + s？
通常，但不如按ctrl + s那样频繁。这是个人喜好和/或团队政策的问题。就个人而言，我会说，当您完成一段功能代码时，无论提交的内容多么小，都可以提交。
什么是分支机构，什么是标签，您如何控制它们？
首先，主干是您进行积极开发的地方。这是您的代码的主线。分支与主线有些偏离。这可能是一个重大偏差，例如以前的版本，或者只是您想尝试的一个小调整。标签是代码的快照。这是将标签或书签附加到特定修订版的方法。
还值得一提的是，在Subversion中，主干，分支和标签只是惯例。没有什么可以阻止您在标签中进行工作或拥有作为主线的分支，或者完全不考虑标签-分支-树干方案。但是，除非您有充分的理由，否则最好遵循约定。
SVN中包含什么？仅源代码，还是在这里共享其他文件？
也是个人或团队的选择。我更喜欢将与构建相关的任何内容保留在我的存储库中。这包括配置文件，构建脚本，相关媒体文件，文档等等。你应该不会在文件中检查需要是每个开发人员的机器上的不同。您也不需要检入代码的副产品。我主要考虑的是构建文件夹，目标文件等。
埃里克·辛克（Eric Sink）于2009年1月出现在SO播客＃36中，他写了一系列出色的文章，标题为《源代码控制方法》。
（埃里克（Eric）是SourceGear的创始人，他销售与SourceSafe兼容的插件版本，但并不可怕。）
只是添加另一组答案：
其他人说，这取决于您的风格。
您面临的最大问题是您多久“集成”一次软件。在测试驱动的开发中，敏捷和Scrum（以及许多其他许多方面）依靠小的变化和持续的集成。他们鼓吹要进行一些小的更改，每个人都可以找到中断并始终对其进行修复。
但是，在较大的项目（例如政府，国防，100k + LOC）中，您根本无法使用连续集成，因为这是不可能的。在这些情况下，最好使用分支进行少量的提交，但仅将能正常工作并准备好集成到构建中的内容带回到主干中。
需要注意的一个分支是，如果对它们的管理不当，可能会使仓库中的工作陷入噩梦，因为每个人都在从树干上的不同位置进行开发（顺便说一句，这是最大的争论之一）。持续集成）。
这个问题没有明确的答案，最好的方法是与您的团队合作，提出最佳的折衷解决方案。
带有Subversion的版本控制是面向初学者和老手的指南。
我认为您必须至少阅读本章的前几章，才能有效地使用Subversion。
对于提交，我使用以下策略：
尽可能多地提交。
每个功能更改/错误修正都应提交自己的提交（不要一次提交多个文件，因为这样会使该文件的历史记录变得不清楚-例如，如果我分别更改日志记录模块和GUI模块，并且一次提交，两种更改都将在两种文件历史记录中均可见。这使得读取文件历史记录变得困难），
不要破坏任何提交的构建-应该可以检索任何版本的存储库并进行构建。
生成和运行应用程序所需的所有文件都应在SVN中。除非它们是单元测试的一部分，否则不应包含测试文件等。
《 TortoiseSVN TSVN手册》是基于Subversion的书，但提供了更多的语言版本。