如何使用 SVN，布兰奇? 标签? 后备箱？

提交频率取决于您的项目管理风格。如果提交会破坏构建(或功能) ，许多人会避免提交。

分支可以以两种方式之一使用，通常是: 1)一个用于开发的活动分支(主干保持稳定) ，或者2)用于替代开发路径的分支。

标签通常用于识别版本，所以它们不会在混合中丢失。释放的定义取决于你。

* 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?

文档、构建所需的小型二进制文件以及其他对源代码控制有一定价值的东西。

对于承诺，我使用以下策略:

• 尽可能经常地承诺。

• 每个特性更改/bug 修复都应该有自己的提交(不要同时提交多个文件，因为那样会使该文件的历史记录不清楚——例如。如果我单独更改日志记录模块和 GUI 模块，并同时提交这两个模块，那么这两个更改将在两个文件历史中都可以看到。这使得读取文件历史记录变得困难) ,

• 不要在任何提交上中断构建——应该可以检索存储库的任何版本并构建它。

构建和运行应用程序所需的所有文件都应该在 SVN 中。测试文件等不应该，除非它们是单元测试的一部分。

其他人说这取决于你的风格。

对您来说，最大的问题是您“集成”软件的频率。测试驱动开发，敏捷和 Scrum (以及许多其他的)依赖于小的变化和持续的集成。他们鼓吹小的改变是可以实现的，每个人都能找到突破口，并且不断地修复它们。

然而，对于一个更大的项目(想想政府、国防、100k + LOC) ，你不能简单地使用持续集成，因为这是不可能的。在这些情况下，最好使用分支来执行大量的小提交，但只将可以工作并准备集成到构建中的内容带回主干。

但是分支需要注意的一点是，如果不能正确地管理它们，那么在存储库中将工作放入主干可能是一场噩梦，因为每个人都是从主干上的不同位置开发的(顺便说一句，这是持续集成的最大论据之一)。

这个问题没有明确的答案，最好的办法是与你的团队合作，想出最好的折衷解决方案。

当我们在这里实现 Subversion 时，我问自己同样的问题——大约20个开发人员分布在4-6个项目中。我没有找到任何有“答案”的好消息来源。以下是我们在过去三年中得出的一些答案:

我们的经验法则是，只要你已经完成了足够的工作，如果修改丢失了，就不得不重做; 有时候我每15分钟左右提交一次，有时候可能需要几天(是的，有时候写一行代码需要一天)

我们使用分支，正如你早期的一个答案所建议的，用于不同的开发路径; 现在我们的一个程序有3个活跃的分支: 1个用于主开发，1个用于尚未完成的并行程序，1个用于修改程序以使用 XML 输入和输出文件;

我们很少使用标签，尽管我们认为我们应该使用它们来识别产品的发布;

想象一下沿着一条单一的道路进行开发。在开发营销的某个时候或者某个状态决定发布产品的第一个版本，所以你在标记为“1”(或者“1.0”等等)的路径上插上一面旗子。在其他一些时候，一些聪明的人决定将这个程序并行化，但是他们认为这需要几周的时间，而且人们希望在此期间继续沿着主要的道路前进。所以你在小路上建了一个岔路口，不同的人在不同的岔路口漫步。

道路上的旗帜叫做“标签”，道路上的岔路口就是“树枝”分开的地方。有时候，树枝也会重新聚集在一起。

--我们将构建可执行文件(或系统)所需的所有材料放入存储库; 这意味着至少源代码和 make 文件(或 Visual Studio 的项目文件)。但是当我们有了图标、配置文件和所有其他东西时，这些东西就会进入存储库。一些文档可以找到进入回购的途径; 当然，任何文档，例如可能是程序不可或缺的帮助文件，都可以找到，而且它是放置开发人员文档的有用位置。

我们甚至把我们的产品版本的 Windows 可执行文件放在那里，为寻找软件的人提供一个单一的位置——我们的 Linux 版本发布到一个服务器上，所以不需要存储。

我们并不要求存储库在任何时候都能够交付最新的版本来构建和执行; 有些项目是这样工作的，有些则不是; 决定权在于项目经理，取决于许多因素，但我认为它在对程序进行重大更改时会崩溃。

正如其他人所说，SVN 书是最好的地方开始和一个伟大的参考，一旦你已经得到你的海腿。现在，回到你的问题。

你多久提交一次? 按 ctrl + s 的频率？

经常，但不像按 ctrl + s 那么频繁，这是个人品味和/或团队策略的问题。就我个人而言，我会说提交当您完成一段功能性代码，无论多么小。

什么是分支，什么是标签，你如何控制它们？

首先，主干是进行主动开发的地方。它是代码的主线。一个分支是一些偏离主线的东西。它可能是一个主要的偏差，就像以前的版本一样，或者只是您想要尝试的一个小调整。标记是代码的快照。这是一种将标签或书签附加到特定版本的方法。

值得一提的是，在 subversion 中，主干、分支和标记只是约定。没有什么可以阻止您在标记中工作，或者拥有作为主线的分支，或者完全忽略标记-分支-主干模式。但是，除非你有一个非常好的理由，最好还是坚持惯例。

什么进入 SVN? 只有源代码还是你在这里共享其他文件？

也是个人或团队的选择。我更喜欢将与构建相关的任何内容保存在我的存储库中。包括配置文件、构建脚本、相关媒体文件、文档等。您应该在每个开发人员的机器上签入需要不同的文件。您也不需要签入代码的副产品。我主要考虑的是构建文件夹、目标文件等等。

再加一组答案:

• 每当我完成一项工作时，我都会做出承诺。有时候是一个很小的错误，只是改变了一行，花了我2分钟去做; 其他时候是两个星期的汗水。另外，根据经验法则，不要提交任何破坏构建的内容。因此，如果您花了很长时间来做某些事情，那么在提交之前使用最新版本，并查看您的更改是否破坏了构建。当然，如果我很长一段时间没有做出承诺，这会让我感到不安，因为我不想失去那份工作。在 TFS 中，我使用这个好东西作为“搁置集”。在 SVN 中，你必须用另一种方式工作。也许您可以创建自己的分支，或者手动将这些文件备份到另一台计算机。
• 分支是整个项目的副本。使用它们的最佳例证可能是产品的版本控制。假设您正在从事一个大型项目(比如 Linux 内核)。经过几个月的努力，您终于到达了向公众发布的1.0版本。之后，你开始工作的版本2.0，你的产品，这将是更好的方式。但同时也有很多人在使用1.0版本。这些人发现了你必须修复的漏洞。现在，您不能修复即将发布的2.0版本中的 bug 并将其发布给客户端——它根本就没有准备好。相反，您必须取出1.0源代码的旧副本，修复那里的 bug，并将其发送给用户。这就是树枝的作用。当您发布1.0版本时，您在 SVN 中创建了一个分支，该分支在那时复制了源代码。这个分支被命名为“1.0”。然后，您继续在您的主源副本中开发下一个版本，但是1.0副本仍然保留在那里，就像发布时一样。你可以在那里继续修复 bug。标签只是为了方便使用而附加到特定修订版本的名称。您可以说“源代码的2342修订版”，但是更容易将其称为“第一个稳定的修订版”。:)
• 我通常将所有与编程直接相关的内容放在源代码控制中。例如，因为我正在制作网页，我也把图片和 CSS 文件放在源代码控制，更不用说配置文件等。项目文档不会放在那里，但是这实际上只是一个偏好的问题。

这里有很多很好的评论，但是还有一些没有提到的是提交消息。这些应该是强制性的和有意义的。特别是分支/合并。这将允许您跟踪哪些更改与哪些 bug 特性相关。

例如，svn commit . -m 'bug #201 fixed y2k bug in code'将告诉任何查看历史的人这个修订是为了什么。

一些 bug 跟踪系统(例如 trac)可以在存储库中查找这些消息，并将它们与票据关联起来。这使得计算出与每个票证相关的更改变得非常容易。

我认为有两种方法可以提高频率:

1. 经常提交，对于每个实现的方法，代码的一小部分，等等。
2. 只提交已完成的代码部分，如模块等。

我更喜欢第一个-因为使用源代码控制系统不仅对项目或公司非常有用，首先它对开发人员非常有用。对我来说，最好的特性是在搜索最佳分配任务实现时回滚所有代码。

我认为主要的问题是心理图片的源头控制是混乱的。我们通常有主干和分支，但是我们会得到不相关的标签/发布或其他影响的想法。

如果你更全面地运用树的概念，它就会变得更加清晰，至少对我来说是这样。

我们得到树干-> 形成树枝-> 生产水果(标签/释放)。

这个想法是，您从一个主干增长项目，然后在主干足够稳定以容纳分支时创建分支。然后当树枝结出一个果子，你就从树枝上摘下它，并把它作为一个标签释放出来。

标签本质上是可交付的，而树干和分支生产它们。

我们的工作策略是这样的(多开发人员团队致力于面向对象框架) :

• 每天从 SVN 更新以获取前一天的更改

• 坚持每天工作，这样如果你第二天生病或缺席，其他人就可以轻松地接替你的工作。

• 不要提交破坏任何东西的代码，因为那会影响其他开发人员。

• 每天做一些有意义的评论！

• 作为一个团队: 保留一个开发部门，然后将预发布代码(QA)移动到生产部门。这个分支应该只有完整的工作代码。