2019-12-25每当有新需求就创建一个或多个feture分支吗？这些feture分支开发完后，需要长期保留吗？作者回复: 可以切分成几个不同的feature分支，这个看需求的粒度。feature分支可以分为本地和远程，如果不需要协作就在自己本地就行，需要协作可以放到远程，结束后就可以关闭feature分支。
2- 2020-01-06对环境分支工作流有点疑问，当设置Master为测试分支。现在有A、B两个都需要测试，都合到了Master分支，现在A测试完成，看视频里说是要把Master分支合到 预发步分支 Pre-Production分支，那这样岂不是把B分支的内容给错误的带到了预发步分支？为什么不把测试完的分支A单独合并到预发步分支呢？
还有最后的上线合并分支也是同样的疑惑，当多个分支的代码都在预发步回归测试，为什么上线的步骤是直接把预发步的分支合到Production发布分支，这样不也是会把正在预发步分支未回归完成的功能带上线吧？想问下这些都是怎么考虑和避免的呢？作者回复: AB都要提交到Master，Pre-Prod是和预生产环境关联的，也就是说到了预生产是不应该做测试的，只能做验证，因为它是和生产一样的环境。更复杂的产品还会有staging1, staging2, staging3环境，这些环境都和分支关联，再通过devops pipeline就可以自动做CI和CD。
1 
2019-12-27基于基线的版本发布还是不太清楚，是不是就指的是发布分枝流？bug fix 是在master上，这样和合并的features不是混在一起了吗？cherry pick就觉得费时费力了。发布分枝3-8-STABLE 是不是应该从3-7-STABLE分出来，而不是从Master分出来？作者回复: 基线是另一个概念，基线是取所有相关文件后打一个标签，形成一个基础稳定版本，比如：“Build1228”，而这些文件可能是来自不同版本的文件组合；bug fix在Master上虽然不是强制的，但这么做的好处是，在发布分支上可以通过cherry-pick引用这个bug fix后形成新的补丁，而后面的发布版本都会在这个bug fix上继续，所以这个bug fix是对所有版本生效的；发布分支3-8-STABLE应该从Master分出来，保证同源，以Master为主干做发布。
1