如何使用SVN，分支机构？ 标签？ 树干？
我一点一点地search了一下，找不到SVN的一个好的“初学者”指南，而不是“我该如何使用这些命令”。 我如何控制我的源代码？
我想清楚的是以下主题：
- 你多久做一次？ 像往常一样会按Ctrl + s ？
- 什么是分支，什么是标签，你如何控制它们？
- 什么进入SVN？ 只有源代码或你在这里分享其他文件吗？ （不考虑版本化的文件..）
我不知道是什么分支和标签，所以我不知道目的，但我疯狂的猜测是，你上传的东西到树干，当你做一个重要的构build，你把它移动到分支？ 那么，在这种情况下，什么被认为是一个主要的构build？
颠覆书是一个很好的信息来源的战略布局你的存储库，分支和标签。
也可以看看：
你是继续在树枝上还是在树干上发展？
分支策略
当我们在这里实现Subversion的时候，我问自己同样的问题 – 大约20个开发人员分布在4到6个项目中。 我没有find任何一个有“答案”的好消息来源。 以下是过去三年我们的答案如何发展的一些部分：
– 尽可能经常地提交; 我们的经验法则是，只要你做了足够的工作，就会犯一个错误，如果修改丢失了，就不得不重做; 有时我会每15分钟左右一次，其他时间可能是几天（是的，有时需要我花一天的时间写一行代码）
– 我们使用分支机构，作为您之前提出的答案之一，针对不同的发展path; 现在为我们的程序之一，我们有3个活动分支：1为主要的发展，1为尚未完成的努力并行程序，1努力修改它使用XMLinput和输出文件;
– 我们很less使用标签，尽pipe我们认为我们应该使用标签来识别发布。
想想发展沿着一条path进行。 在某个时间或开发状态下，营销决定发布产品的第一个版本，所以你在标有'1'（或'1.0'或你有什么）的path上植入一个标志。 在另一些时候，一些明亮的火花决定平行的程序，但决定，这将需要几个星期，人们希望继续沿着主要道路同时。 所以你在路上build立一个叉子，不同的人在不同的叉子上漫步。
道路上的旗帜被称为“标签”，道路上的叉子是“分支”所分开的地方。 偶尔，分支也会一起回来。
– 我们把构build一个可执行文件（或系统）所需的所有资料放入存储库; 这意味着至less源代码和make文件（或Visual Studio的项目文件）。 但是当我们有图标和configuration文件，以及所有其他的东西，进入存储库。 一些文件进入回购; 当然任何文档，如可能是该程序不可或缺的帮助文件，都是有用的，可以放置开发者文档。
我们甚至把我们产品发布的Windows可执行文件放在那里，为寻找软件的用户提供一个单一的位置 – 我们的Linux发布到服务器，所以不需要存储。
– 我们并不要求存储库在任何时候都能够提供最新版本的构build和执行; 有些项目是这样工作的，有些则不行; 这个决定取决于项目经理，取决于很多因素，但是我认为在对一个项目进行重大改变的时候，这个决定被打破了。
* How often do you commit? As often as one would press ctrl + s? 尽可能经常地。 代码不存在，除非它在源代码控制之下:)
频繁提交（此后更小的更改集）可让您轻松地整合更改，并增加不会破坏某些内容的机会。
其他人指出，你应该承诺，当你有一个function块的代码，但我觉得有用的是更频繁地提交。 几次我注意到我使用源代码控制作为一个快速撤消/重做机制。
当我在自己的分支上工作时，我更愿意尽可能地提交（字面上按照我按Ctrl + s）。
* What is a Branch and what is a Tag and how do you control them?
阅读SVN书 – 这是一个你应该从学习SVN时开始的地方：
- 什么是分支？
- 标签
* What goes into the SVN?
文档，构build所需的小型二进制文件以及其他具有一定价值的内容都将转到源代码pipe理。
下面是关于提交频率，提交消息，项目结构，在源代码控制下放置什么以及其他一般准则的一些资源：
- 版本控制的最佳实践（我自己的博客）
- 早入住，经常入住（编码恐怖） （这里的评论含有很多好的build议）
- KDE的提交策略
这些堆栈溢出问题还包含一些可能有用的有用信息：
- 在混合两种或更多种语言（如Java和C ++）时组织源代码库
- 一个好的提交信息的build议：格式/指南？
- 多久提交一次源代码pipe理更改？
- 学习版本控制，并学习它很好
关于基本的Subversion概念，如分支和标记，我认为这在Subversion的书中有很好的解释。
正如你在阅读这个主题后可能意识到的那样，人们对这个领域的最佳做法的看法往往是不一样的，有时是相互矛盾的。 我认为你最好的select是阅读其他人在做什么，并select你觉得最有意义的指导方针和做法。
如果你不明白其目的或不同意背后的理由，我认为不采取这种做法是一个好主意。 所以，不要盲目地遵循任何build议，而是要自己去思考你认为最适合你的东西。 另外，尝试不同的做事方式是学习和发现最佳工作方式的好方法。 一个很好的例子就是如何构build资源库。 没有正确或错误的方法去做，而且在实践中经过实际尝试之后，往往很难知道自己喜欢哪种方式。
提交频率取决于您的项目pipe理风格。 许多人不会承诺，如果它会打破构build（或function）。
分支可以以两种方式之一使用，通常是：1）一个用于开发的活动分支（并且树干保持稳定），或2）用于替代的开发path的分支。
标签通常用于识别发行版，所以他们不会迷失方向。 “释放”的定义取决于你。
我认为主要的问题是源头控制的心理图景混乱。 我们通常有树干和分支，但是我们得到了无关的标签/释放的想法，或者是对这种影响的东西。
如果你更彻底地使用树的想法，它会变得更清晰，至less对我来说是这样。
我们得到树干 – >forms分支 – >产生水果（标签/版本）。
这个想法是，你从一个树干发展项目，然后一旦树干足够稳定，以支持分支，然后创build分支。 然后，当分支已经产生了水果，你从分支采摘，并作为标签释放。
标签基本上是可交付成果。 干线和分支产生它们。
正如其他人所说， SVN书是最好的地方开始，一旦你已经得到你的海腿很好的参考。 现在，对你的问题…
你多久做一次？ 像往常一样会按Ctrl + S？
通常，但不像按Ctrl + S一样频繁。 这是个人品味和/或团队政策的问题。 就个人而言，我会说，当你完成一个function的代码块，但是很小。
什么是分支，什么是标签，你如何控制它们？
首先，树干是你积极发展的地方。 这是你的代码的主线。 一个分支与主线有些偏差。 这可能是一个重大的偏差，像以前的版本，或只是一个小调整，你想尝试。 标签是您的代码的快照。 这是将标签或书签附加到特定修订的一种方法。
值得一提的是，在颠覆中，主干，分支和标签只是惯例。 没有什么能阻止你在标签上做工作，或者在你的主线上有分支，或者一起忽略标签分支干线scheme。 但是，除非你有一个很好的理由，否则最好坚持惯例。
什么进入SVN？ 只有源代码或你在这里分享其他文件吗？
也是个人或团队的select。 我更喜欢在我的仓库中保留与构build相关的任何东西。 这包括configuration文件，构build脚本，相关的媒体文件，文档等。您不应该检查在每个开发人员的机器上需要不同的文件。 您也不需要检查代码的副产品。 我主要考虑构build文件夹，对象文件等。
Eric Sink于2009年1月出现在SO播客＃36上，在“ Source Control How-to”的标题下撰写了一系列优秀的文章。
（Eric是SourceGear的创始人，他们销售的是SourceSafe的插件兼容版本，但没有可怕性）。
只是添加另一组答案：
- 每当我完成一项工作，我就承诺。 有时候，这是一个微小的错误修正，只是改变了一行，花了我2分钟的时间; 其他时间则是两周的汗水。 此外，作为一个经验法则，你不承诺任何破坏构build。 因此，如果你花了很长时间去做某件事情，那么在提交之前先拿最新版本，看看你的修改是否破坏了构build。 当然，如果我长时间没有承诺，这让我感到不安，因为我不想放弃这项工作。 在TFS中，我使用这个好东西作为“shelvesets”。 在SVN中，您必须以另一种方式解决问题。 也许创build自己的分支或手动备份这些文件到另一台机器。
- 分支是你整个项目的副本。 他们使用的最好的例子可能是产品的版本。 想象一下，你正在一个大型项目（比如Linux内核）工作。 经过数月的汗水，你终于到达1.0版本，你释放公众。 之后，你开始工作在2.0版本的产品，这将是更好的。 但同时也有很多人在使用1.0版本。 这些人发现你必须修复的错误。 现在，您无法修复即将到来的2.0版本中的错误，并将其发送给客户端 – 它根本没有准备好。 相反，你必须提取一个1.0源代码的老版本，修复那里的错误，并将其发送给人员。 这是分支机构的目的。 当你发布1.0版本的时候，你在SVN中创build了一个分支，在这个分支上复制了源代码。 这个分支被命名为“1.0”。 然后，您继续在主要源代码副本中的下一个版本上工作，但是1.0版本仍然保留在发布时刻。 而且你可以继续修复那里的错误。 标签只是附在特定修订版上的名称，便于使用。 你可以说“修改源代码2342”，但是更容易把它称为“第一次稳定版本”。 🙂
- 我通常把所有的东西放在与编程直接相关的源代码控制中。 例如，因为我正在制作网页，所以我还将图像和CSS文件放在源代码控制中，更不用说configuration文件等。项目文档不在那里，但实际上这只是一个优先select。
其他人则表示，这取决于你的风格。
你最大的问题是你“整合”你的软件的频率。 testing驱动的开发，敏捷和Scrum（以及许多其他）依赖于小的变化和持续的整合。 他们鼓吹做出小小的改变，每个人都会findrest时间并随时修复。
然而，在一个更大的项目（认为政府，国防，10万+ LOC），你根本无法使用持续集成，因为这是不可能的。 在这种情况下，使用分支来做很多小的提交可能会更好，但是只要将它们重新引入到主干中，就可以将其工作并准备集成到构build中。
但有一点需要注意的是，如果pipe理不当，可能会使存储库中的工作变成一场噩梦，因为每个人都是从干线上的不同位置发展而来的（顺便说一句，持续集成）。
在这个问题上没有明确的答案，最好的方法是与你的团队合作，想出最好的折中解决scheme。
版本控制与Subversion是初学者和老手的指南。
我不认为你可以有效地使用Subversion，而不必阅读至less前几章。
对于提交，我使用以下策略：
-
尽可能经常地做。
-
每个function更改/错误修复应该得到它自己的提交（不要一次提交多个文件，因为这将使该文件的历史不清楚 – 例如，如果我独立更改日志logging模块和GUI模块，我立即提交，两个文件历史都会显示这两个变化，这使得阅读文件历史logging变得困难），
-
不要打破任何提交的构build – 应该可以检索任何版本的资源库并构build它。
所有构build和运行应用程序所需的文件都应该在SVN中。 testing文件等不应该，除非它们是unit testing的一部分。
这里有很多好评，但没有提到的是提交消息。 这些应该是强制性和有意义的。 特别是分支/合并。 这将允许您跟踪哪些更改与哪些错误function相关。
例如svn commit . -m 'bug #201 fixed y2k bug in code' commit . -m 'bug #201 fixed y2k bug in code'会告诉任何人查看历史logging的修订内容。
一些错误跟踪系统（例如trac）可以在存储库中查找这些消息并将它们与门票相关联。 这使得确定每张票的相关变更非常简单。
我们工作的策略是这样的（多开发团队在面向对象的框架上工作）：
-
每天从SVN更新以获取前一天的更改
-
如果你第二天生病或缺席，每天都要进行承诺，其他人可以轻松地从你离开的地方接pipe。
-
不要提交破坏任何内容的代码，因为这会影响其他开发者。
-
在小块上工作，每天都会做出有意义的评论！
-
作为一个团队：保留开发分支，然后将预发布代码（用于QA）移到生产分支中。 这个分支只能有完整的工作代码。
TortoiseSVN TSVN手册是基于颠覆书 ，但有更多的语言。
我认为有两种方式：
- 经常提交，对于每个实现的方法，小部分代码等
- 只提交完成的代码部分，如模块等
我更喜欢第一个 – 因为使用源代码pipe理系统不仅对于项目或公司是非常有用的，首先它对于开发者是有用的。 对我来说，最好的function是回滚所有的代码，同时search最佳分配的任务实现。
