使用分支作为单独开发人员有什么优势？

首先，我知道已经问过许多关于VCS作为单独开发人员的问题，但是它们通常过于广泛。这仅涉及分支，并且仍然被标记为重复...假定的重复再次被标记为另一个问题的另一个重复，该问题过于广泛且与分支无关。这就是我的问题的独特之处。

使用分支作为单独开发人员有什么优势（如果有）？即使在单独开发环境中，我也经常看到它的建议，但是据我所见，除了使用“主”主干进行开发，并分支工作以准备发布版本的代码外，我还看不到我可以利用分支的力量（例如，划分新功能），而不会使整个开发过程过于复杂。

优势与开发人员群体的优势大致相同。通过使用始终可发布的master分支以及用于开发新功能的feature分支，您可以始终释放master。在使用功能时发现重要错误？切换分支，修复，发布，切回并继续开发。

也许这是一个爱好项目，并且您喜欢能够在此功能上有所作为，随心所欲。您基本上是在按时间划分来模拟多人团队。

DVCS在克隆上进行的隐式分支意味着，权威存储库上的正式分支与协调人有关，而与协调发展方向无关，甚至一个人也可以做到。

长期发展

对于一个长期运行的开发功能（如果不适合您的发布周期），单人团队分支将非常有用。

您可以为分支机构进行为期数月的跨度更改，但仍可以定期从主分支机构推送任何日常的错误修复或更改。

与单个分支中的“开关”相比，这具有优势，因为您的主分支始终处于可部署状态，并且可以确保长期运行的功能中的任何内容都不会影响其他先前测试的代码。

实验功能

分支对于您可能希望对其进行原型设计的功能也很有用，但是可能永远不会使其成为已部署的代码。在最终被我丢弃的分支上完成这些操作意味着您永远不会不必要地污染您的主代码库。

我将其用于重要的网站维护。我是唯一的开发人员，但我拥有一个主管，开发和发行分支。

我的网站设置工作流程如下：

1. 使可行的主分支。进行初始提交。

2. 结帐开发分支。不要做任何事情，将功能开发为合并到master的测试缓冲区。

3. 结帐问题分支。对问题进行编码，完成后将其投入开发，查看是否出现任何问题，合并冲突等...修复这些问题。

当将足够多的问题合并到可发布的开发中，并且已对开发进行了稳定性测试时，请将开发拉入母版。

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

这样，您就可以在开发中获得完整的测试集合，可以在其中测试稳定性，问题等……而不必冒险伤害Master并在有害的情况下回滚提交。

另外，通过使用各个分支进行提交，您可以“离开”您已经完成的工作，重新开始其他工作以解决更紧急的问题并尽早推出。

在现实生活中，我通常只有一个发行分支，然后将其分支发展并掌握。有时这很乏味，但是至少每两个月一次，我必须丢下工作，因为有人认为我必须制造RightNow™，这样我才能快速切换回基本状态，完成此操作然后再继续我所在的地方。特别是对于需要花费数周时间的大型项目，这是我可以快速切换分支机构的天意。

考虑以下情况：您始终在主分支上工作，并且正在使用AwesomeCodeThing™，使您的Master分支无法进行心脏手术，并且弹出YugeBug™，需要紧急修复，否则成千上万的用户会向您抱怨BigProblems™
The在这种情况下快速解决问题的唯一方法，

1. 检查您以前的提交，
2. 查看上一次稳定提交的时间（可以选择是否进行cursing）
3. 回滚到该提交
4. 进行修复，将修复推向生产
5. 解决您现在试图回到AwesomeCodeThing™状态的所有冲突和问题
6. 放弃，哭泣并开始工作。（可选）

如果使用分支：

1. 结帐大师
2. 创建分支UrgentFix™并修复问题
3. 将UrgentFix™拉入主机
4. 推向生产
5. 合并大师发展
6. 合并成AwesomeCodeThing™
7. 喝啤酒，继续工作。

分支使同时处理多个功能变得更加容易，这在项目过程中更改优先级时非常有帮助。

假设您认为某个功能现在更为重要。也许您急需修补实时系统中的关键错误。您可能需要长时间与客户一起使用多个功能，并且可能想分别演示每个功能的进度。也许您刚刚读到一个关于讨厌的零日漏洞的文章，并想在客户了解该漏洞之前将其投入使用。

如果您对每个功能/修补程序使用分支，则通常更容易，更干净，更快捷地隔离和部署这些修改，而不是对所有功能都使用单个分支。无论您是单独的开发人员还是团队的一员，这都是正确的。

至于实际过程，我发现git flow效果很好。Daniel Kummer的git flow备忘单是很棒的资源，即使您不使用git，也值得一看。

正如其他张贴者所提到的，其优势与团队合作基本相似：能够独立开发和测试功能，为修补程序/产品部署维护单独的主分支，进行实验的能力。

就我个人而言，如果我知道我正在工作的领域非常好，我通常倾向于在硕士方面工作，这只会增加分支的开销，因为无论如何我都会合并它们。

但是，如果对所做的更改有任何犹豫，我将分支，并且只有PR符合分支的预期行为并且通常经过充分测试后，才进行PR /合并。这样，如果我发现回滚是最佳解决方案，那么它是一次提交而不是整个提交（我永远不记得回滚一系列提交的语法，但是一次提交很容易）。