我是源/版本控制领域的新手，我一直在做尽可能多的阅读，以便了解人们用于自己的源/版本控制的不同技术。
我注意到的一件事是，开发人员的方法在两个（可能更多？）组中有一个非常明显的突破：一组更喜欢将其主干保持在一个始终稳定的状态，并执行所有维护和未来的开发。分支机构，而其他人则更愿意在后备箱中进行所有开发，并将其保持在不太稳定的状态。
我很好奇StackOverflow的社区更喜欢什么，或者你有自己的方法。
注意：如果它有助于定制答案，我应该注意到我是一个单独的开发人员（在同一个项目中最多会有两三个人）主要在ASP.NET和SQL Server 2005中工作
答案 0 :(得分：14)
我确信你已经注意到在网上搜索关于这个主题的答案，这是最好的答案是“它取决于”的事情之一，并且正如大多数答案所表明的那样，它是一个在您希望能够提交/合并新代码的容易程度与管理可以轻松回滚以进行支持或调试的广泛版本历史记录之间进行权衡。
我在一家小公司工作，这意味着在任何特定时间，我们可以在尚未提交到存储库的开发人员计算机上拥有3或4个不同版本的代码。我们使用TortoiseSVN作为我们的版本控制系统，这使我们能够毫不费力地进行分支/合并，并且能够非常轻松地查看更新日志或将本地副本还原到早期版本。
基于你的问题，我想我们会属于那些试图始终保持稳定Trunk的开发人员群体，我们会在将新代码合并到Trunk之前对其进行分支和测试。我们还努力保留每个版本的“快照”，以便在必要时，我们可以轻松检查早期版本并重新构建它，而无需为将来的版本添加任何新功能（这也很棒）跟踪错误的机制，因为您可以使用早期版本的代码来帮助确定特定错误何时首次引入代码。但是，有一点需要注意的是，如果您的应用程序引用与您的版本分开维护的公共代码代码，你也需要跟踪它！）。
在存储库中，它最终看起来像这样：
中继线
v1.0.2.x发布
v1.1.1.x发布
v1.2.1.x开发＆lt; - （这将合并回Trunk，并替换为Release文件夹）
当我第一次来到公司时，我们的版本结构并不那么复杂，根据我的经验，我会说，如果你有任何需要跟踪早期版本，那么值得付出努力像这样的东西（就像我之前说过的那样，它不一定非常像这样，只要它符合你的个人需求），保持记录良好，以便所有贡献者都可以维护它（替代方案是创建者结束“保姆”回购，很快就会浪费时间，并鼓励所有开发人员遵循它。一开始可能感觉很费劲，但是当你第一次需要利用它时，你会感激不尽。
祝你好运！答案 1 :(得分：6)
我在后备箱中完成所有开发工作。我是一个单一的开发人员，不想处理分支的麻烦。当我的代码稳定时，我只标记当前版本。例如，我标记版本1.0,2.0 beta，2.0版本候选版本1，版本2.0等。如果您维护旧版本的错误修复和支持，分支可能是更好的选择但是因为我不这样做我不喜欢不用担心。
答案 2 :(得分：4)
差异可能与给定版本控制系统中的合并有多痛苦有关。
使用git，分支和合并几乎毫不费力，所以这是我保持主人干净并在分支机构完成所有工作的常用工作流程。 svn中的分支和合并，特别是在以前的版本中，并不是那么便宜和容易，因此当我使用svn时，我倾向于直接在主干上工作。
答案 3 :(得分：2)
始终稳定。即使我是一个开发人员 - 几乎特别是如果我是一个单独的开发人员。
给我一棵破树意味着要知道我应该做什么的一种方法。
分支机构以及稳定版本都会发生重大变化，并且可以在任何给定点进行最小的变更单元，以便继续以良好的速度向前发展。
答案 4 :(得分：2)
我总是使用主干作为代码头。通常新的开发代码在那里。
我们分支发布，我们可能会分支进行“大”破坏稳定的实验。
当我们修复bug时，他们首先进入main，然后在需要时将它们合并（后端）到适当的版本分支。
如果大型实验成功，它就会被合并回主力。
我们在版本分支和主要版本中使用标记来构建编号。这样我们就可以回到特定版本并构建（如果必须的话）。
答案 5 :(得分：2)
这是我们遵循的方法： 应从行李箱中取出任何稳定的释放装置。任何进一步的工作或修改都应该在工作分支内部，并且在准备发布时应该与trunk合并。
如果有多个独立的开发项目，每个组都应该有分支机构，他们应该定期与trunc同步，并在准备好后将其合并回主干。
答案 6 :(得分：1)
我正在寻找始终稳定的行李箱。您需要能够随时重建最新的稳定版本......
答案 7 :(得分：1)
在您的情况下，我强烈建议避免大量分支。这真的是一个相当先进的过程，对于小型项目和小型团队来说并不是必需的。
答案 8 :(得分：1)
尝试并保持简单开始，我总是尝试使用已知的工作版本来重现测试和部署等。根据您的存储库，您可以使用版本号（SVN），或只标记已知的工作版本因为它们是必需的。
如果您发现有多个人触摸相同的文件，那么您需要考虑一个分支策略，除了这样一个小型开发团队，它只是不必要的开销...（IMO）
答案 9 :(得分：1)
一个方面是变化处于不稳定状态的时间长短。
当我所做的更改可能影响其他人或每晚构建时，我会在分支上完成工作，并在稳定时合并。
当我所做的更改不会影响其他人（因为它是我在家的私人代码，而不是工作中的代码），那么我可以检查非工作中间状态，如果这是我想要的。有时，我会连续制作一些不稳定的签到;只有我受影响且工作流程是连续的，这对我来说没问题。如果我在几年后回来（而不是仅仅几天）并且事情不起作用就会出现问题（只要我有这样的一个缺点 - 我确实有一些项目仍然存在在开发和维护方面，已经足够投票了。）
我使用标记的变体来实现可重复的构建 - 所以如果我需要回到稳定版本来修复bug，我可以使用标记信息来做到这一点。能够按需获得稳定版本至关重要。
答案 10 :(得分：0)
一个关键的区别是大文件平均有多大。大文件（1000行+）往往有许多独立的更改，可以轻松自动合并。因此，其他人正在积极更改您即将开始工作的文件的事实可能是无趣的，所以如果系统很难发现它就没问题。
因此，您倾向于最终获得具有大量分支和轻松合并的VC策略。新功能写在新的分支中。
如果您正在使用像Java这样的语言来处理OO设计中典型的较小，高度内聚的文件，那么这种意外冲突就会非常罕见。即使作为一个人为的例子，很难提出两组可以对类（和相应的JUnit测试用例）进行的更改，这些更改可以合理地单独进行，然后通过文本合并工具自动编织回来
如果你进行了大量的重构（重命名和拆分文件），那么就会更加强调合并工具。
因此，您最好采用具有可识别且可用的稳定中继线和最小分支的VC策略。
在第一种方法中，新功能在新分支中编写，并在完成时合并。在第二个中，它以新文件写入，并在完成时启用。
当然，如果你做第二次，你肯定需要强大的保护，从基线变得无法使用任何时间长度（即持续集成和强大的自动运行测试套件）。