Answers:
在大多数情况下，这是到目前为止我们所使用的任何VCS所采用的常规工作流程。对于某些（CVS，SVN），它很难做到，而对于GIT，它却是微不足道的。也就是说，我有两句话：
首先，关于功能分支有两种思想流派：
（1）这篇文章似乎暗示了这一点。合并提交的问题是所谓的Evil Merges。具体来说，那些加入了其中一个分支的功能已更改了语义但自动合并的开发路径，但是自动合并无法修补来自另一个分支的代码中的所有出现。众所周知，以这种方式引入的回归很难调试。作为GIT用户，您通常可以对回归轻松得多，因为您必须git bisect自动找到回归的原因。但是，在所描述的情况下，git bisect将指出合并提交，这对您完全没有帮助。
（2）通过尽量保持线性历史避免了这个问题。那些相反的基准要求重新基准使您无效。
就我个人而言，我坚定地站在阵营（2）中，因为我更重视git bisect结果的有效性，而不是潜在的测试覆盖率损失，这可以通过使用适当的CI系统轻松弥补。
其次，我为我决定，在开发人员之间进行推送很少是一个好主意。涉及到一些安全问题，每个人都可以进入您的盒子中进行提取，或者在本地运行git-deamon，更重要的是，在规模不小的团队中，监督可能会迅速消失。
就是说，我都支持暂存库（有时也称为草稿），该暂存库允许子团队通过中央服务器共享其进行中的工作，但是该中央服务器与主服务器不同（通常是向外的）。面对，如果不是公开的话）。通常，每个子团队将为其自己维护一个主题分支，并且CI系统将所有主题分支的八达通定期合并到一个大的集成分支中，抱怨冲突和构建错误。
git bisect当时也是保持扁平策略的原因。
git bisect一个人无关。当功能部件A更改功能部件B也使用的功能时，就会发生这种情况。合并之前，所有测试都会同时通过A和B，但是由于A和B之间的更改不兼容，合并测试可能会中断-但git bisect无法部分将一个分支应用于另一分支，因此，唯一的线索就是合并提交是引入错误的时间。
我目前正在进行大规模和长期的重构（将应用程序从一个转换为另一个GUI工具包）并执行成功的以rebase为中心的工作流，因为其他团队成员继续致力于新功能：
主要有两个主要分支，即master开发新功能的toolkit-conversion分支和分支。最重要的规则很简单：仅执行toolkit-conversion分支中与转换相关的事情。每当master（旧的GUI工具包）中可以执行某些操作时，我都会在其中进行操作，并将toolkit-conversion更改重新部署到新的master头上。另一个规则是保持toolkit-conversion分支很短。因此，我经常使用reset，cherry-pick，amend-commit和rebase来将较小的提交与较大的提交（最终具有相同的目的）粘合在一起。当我尝试了某些无法很好地“撤消”更改的工作时，或者在使用临时帮助程序代码重构了某些代码之后，这也可以正常工作。
我决定不将更改从分支合并master到toolkit-conversion分支，因为这会使重新建立早期提交的基准变得更加困难，以使分支保持整洁并易于查看。此外，合并可能会导致冲突，其解决方案的保持力不如保持干净的历史记录高。
当然，此工作流程也有缺点。最重要的是，它仅对一个人有效。每当我在将toolkit-conversion分支重新建立基础之后强行推入分支时master，将其拉到另一个存储库上就变得很困难（自动重新定位到跟踪分支通常会因冲突而失败）。
最后，我的toolkit-conversion分支仍然简短，整洁且易于查看。我无法想象使用SVN这样强大的功能。
在我目前正在工作的公司中，一段时间以来，我们一直在应用这种相同的分支模型的变体。我们也一直在使用scrum，因此我们按故事工作流进行分支。
到目前为止，我们唯一遇到的问题是，当团队足够大并且可以启动多个故事并且这些故事相互依赖时，将分支之间的更改合并并返回到主控变得有些混乱。
除此之外，这已被证明是值得信赖的:)。
您是否使用此或类似的git分支工作流程？
我们在工作中使用类似的工作流程，但稍微复杂一些。但是，由于我已经阅读了很多篇文章，因此它深受此工作流程的启发。我什至在办公桌旁用彩色打印了分支模型的pdf :)
您认为这是一种有效的方法吗？
富有成效。您如何定义生产力？好吧，在我看来，最重要的是要拥有高质量的东西，至少要一直努力达到更高的质量。不断改进流程等。如果您可以生成高质量的代码，则可以从中受益。因此，问题实际上是：这会提高软件的质量吗？我对此的回答肯定是。
我最喜欢这种类型的分支模型的地方是，它引入了不同质量级别的分支。图片中越右边，稳定性和质量越高。master分支是神圣的，对它的所有提交都应被视为该软件的稳定版本。向左移动越多，实验性越强，稳定性越低。
一旦测试了新功能和错误修复，就可以逐渐从左向右转移它们，从而在知道代码满足您所要求的质量要求时准确地高质量地移动代码。好吧，至少从理论上讲，因为您不能对所有内容进行100％的测试，并且可以肯定地知道该代码不包含任何错误，因为它始终会包含错误。但是，它使您可以保持高度的信心。
作为程序员，没有什么比在没有人对代码有信心的系统中工作更能吸引人的了，因为他们知道代码只是很烂，并且其中包含大量的错误。
您看到这种方法有什么缺陷吗？有潜在的不利之处吗？
重要的是要仔细考虑您的分支机构模型，以使其适合您组织的需求。仅仅因为此模型对某些人有效，并不一定意味着它对其他人来说是最佳或理想的。
即使在这种情况下，也总是需要权衡取舍。权衡之一是分支数量与复杂性。通过引入许多不同的分支类型，您增加了工作流程的复杂性。例如，当人们试图通过更改几行代码来修复一个简单的错误时，总是强迫人们创建一个新的功能分支可能是错误的。
我们都知道，错误的解决或多或少复杂。因此，当发现一个小错误时，您可能希望减少复杂性和管理，以消除额外的开销，而让人们直接提交给master或development分支。但是，随着修补程序的性质变得更加复杂，为它们创建新分支的额外开销值得。特别是如果您不确定它的大小和长度，或者您想改善与其他开发人员之间的协作。
如果您有更好的方法，您是否愿意分享或提供文章或相关讨论的链接？
毫无疑问，这是一个好方法，它可能适合大多数情况，因为我们大多数人都具有相似的开发过程，但它可能并不适合所有人。我强烈敦促您仔细考虑一下如何立即处理代码，并尝试创建一个适合您已有的分支模型。
最重要的一点是开始使用git，其余的自然而然。从简单开始，逐步完善！有创造力！
干杯