2019-09-13看完这篇后，最大的感受就是Git是个宝库，之前对它的使用还停留在表面，我要去找本书系统学习一下。作者回复: Git的却很强大，很方便。确实也需要投入时间学习。我2010年初始Git的时候，找一个Git老手讨教，他非常热心地给我讲了一个半小时，我还是迷迷糊糊。不过现在想起来还是很感激他 ：）
这个链接是一个有趣的图形化Git学习工具。你可以看看：http://git-school.github.io/visualizing-git/#cherry-pick 6
2019-09-07像 Facebook 这种主干（master）开发模式，每个人的代码每天都会合入到 master，实际中经常会有这样的情况：A、B 两个 feature 同时在进行，但上线时间不同，A 先上，那基于这种模式，A 上的话就会带入 B 的代码，难道 A 上的时候再基于上一个稳定版本 tag 再 cheery-pick A 的所有功能代码到测试分支？作者回复: 如果B的功能还没有准备好给用户使用，可以使用功能开关隐藏。
2
2019-09-06听起来trunk-base这种方式基本和集中式的svn和perforce是一个思路，那疑问就是为啥不直接用perforce,收费？学习成本？需要额外的运维投入？
trunk-base针对pull request的方式还有一个疑问，怎么做pre checkin的code review来控制入库代码的质量？
我能想到的好像还是集中式的那种checkin必须使用固定的工具，这个工具会去自动获取这个提交的code review，如果没有就不允许checkin.作者回复: > 听起来trunk-base这种方式基本和集中式的svn和perforce是一个思路，那疑问就是为啥不直接用perforce,收费？学习成本？需要额外的运维投入？
非常好的问题。我觉得至少有以下几个好处：
1. 分布式的好处，使得开发人员在本地操作速度快。
2. 分布式的另一个好处。虽然我在文章中没有写，使用的频率也不是很高，但是开发人员的个人repo是可以互相推送代码进行合作的，不经过统一的中央repo。
3. Git开源。事实上，2015年左右，Facebook每天有太多的commits，所以Git的性能逐渐不能满足。于是Facebook尝试修改Git的代码。不过因为Git社区觉得Git代码仓不应该超级大，所以没有合作成功。最终Facebook从Git转向了Mercurial（hg）。ht是另一个类似Git的分布式代码仓管理系统。hg也是开源，Facebook通过提高hg解决的commits太多的问题。这就是使用开源的好处。这里强调一下，虽然Facebook从Git转到了hg，但是今天文章中讨论的分支策略对hg也是有效的。
4. Git免费
5. 在进行周部署，日部署、热修复部署中各种分支处理，Git的比svn，perforce强大。这一点因为我对Perfoce不是特别熟悉，不是100%确定。
> trunk-base针对pull request的方式还有一个疑问，怎么做pre checkin的code review来控制入库代码的质量？
我能想到的好像还是集中式的那种checkin必须使用固定的工具，这个工具会去自动获取这个提交的code review，如果没有就不允许checkin.
这个的确是一种方式。比如使用Phabricator进行Code Review的时候，Phabricator对外提供接口。在开发者尝试push代码到Git Server的时候，Git Server可以会去Phabricator检查用户的commit有没有通过Code Review。
另外一个方式是让代码审查工具，比如Phabricator，Gerrit，在Code Review通过之后，代替开发者Push commit。 2 2- 2019-09-13全栈是趋势，这是不可避免的。
全栈不意味着所有事情都亲力亲为，从个人发展的角度来说，肯定还是需要先在某个方向上做专做精，然后对项目涉及的其他方面由浅入深的逐渐熟悉。在读圣贤书的同时，也要知窗外事。作者回复: 👍👍👍
1 
2019-09-12想问一下老师，Facebook的开关是配置系统统一管理的吧？那么多功能分支，都靠开关管理，如何做好多个配置开关有效快速管理？作者回复: 是统一管理的。这个系统叫GateKeeper。推荐你看看这个，有很多细节：https://www.quora.com/How-does-Facebooks-Gatekeeper-service-work
2 1
2020-02-02从上面文章中获取，您的cherry-pick 策略都是在master上进行修复，然后cherry-pick 至周部署分支或热修复分支。
针对这个场景，我有以下几个问题
1. master分支每天有很多提交，其分支代码与周部署分支&热修复分支很大可能已经不一致了，如何保证cherry-pick质量？为什么不是从待发布分支 cherry-pick 至 master 分支呢？
2. cherry-pick 操作是自动化，还是手动的？
2019-12-27facebook 的原子化提交这块，开发是以什么标准拆分，确保原子性的。老师能否帮忙介绍下。谢谢作者回复: 几个标准:
1. 提交不要超过一个功能。如果是bug fix的话可以有几个类似的fix放到一起（因为提交太小也不好）。
2. 如果功能较大，提交应该是一个功能的子功能
3. 这个提交需要能够入master库后不会break master。也就是说，该提交在入master之后，上可以从这个提交的位置发布一个产品。当然可能会有Bug，但是不能出现功能不能用的情况。要么功能实现完成，要么用户看不到。
另外大小上来说，并没有严格规定多少文件多少行。但是要让代码审查者审查起来不能太困难。
2019-11-20有没有toB的分支模型建议，多客户，核心功能相同，但是多个客户可能有不同的功能集合或者定制作者回复: 会持续开发新的功能吗？如果可以的话，推荐一个分支，使用功能开关控制。如果不行，就只能使用多个发布分支。
2019-11-15facebook 的 Trunk-based 模式感觉没有 code review 流程介入呀，开发者直接push到master就测试上线了吗？作者回复: 有Code Review呀，请参考第5篇文章以及第12，13篇。
2019-11-01学习了。
以前就我一个人用git时，只能在官网（https://git-scm.com/book/zh/v2）看看文档。
很多命令都不知道在什么场景下使用。
之前看耗子书关于分支管理的文章，也是云里雾里，很多命令不知道为什么那么用。
现在新工作环境中，由于需要跟别人协作，用的git命令也是越来越多了。
现在再来看老师的这篇文章，就不再吃力了。
我现在很喜欢git rebase 和 git cherry-pick。
我也很努力的保持分支线性，看上去好看。😄
之前很小的提交都是用git merge -no-ff来合并的。
总之，这个东西是熟来生巧。展开作者回复: git 很好玩的！对提高个人效能很有用。
2019-09-17老师，为什么用的是rebase而不是merge作者回复: 因为它可以确保线性的代码提交历史，从而容易定位问题。请参考本文中的"能够确保线性的代码提交历史"部分。
2019-09-16主干开发模式，对于开发的拆分能力要求很高，同时从测试的角度，又怎么确保整个项目和产品功能的完整性呢？作者回复: DevOps，测试左移，测试右移都是比较有效的办法。后面的文章，会有比较详细的介绍，敬请期待。
2019-09-07老师能不能讲讲移动端的开发管理，看了几篇都是后端的集成和发布流程作者回复: 前边描述的各种原则，在移动端后端都是一致的，比如说持续开发，持续集成，持续交付等。
就拿在iOS的Facebook APP 的开发做例子。首先他们也是采用单主干的开发分支模式。要求代码提交的原子性，以及master分支上代码的线性历史。在持续集成方面。他们也是使用的Phabricator作为历程和质量控制中心，进行各种各样的代码入库前检查。在持续交付方面。他们也是采用了和后端类似的方式，每隔一定时间进行一次全量的构建和验证。
当然，也会有一些差别。我在后面的文章中会找机会详细描述。
感谢你的提问！
2019-09-07看到今天，感觉研发和代码越来越有趣了XD作者回复: 对大家有用，让大家觉研发有趣，感觉写文章越来越有趣了XD
2019-09-06各种分支管理策略，学习！问下，基于base开发的这种方式，是不是根据时间线，截止某一时间点（或者某个版本号之前的），代码验证过了，就可以上线了，而不是根据业务功能的先后紧急！作者回复: 对的。这种方式是发布周期与功能解耦。版本火车一列一列发出去。功能开发者自己决定把commit搭乘哪一列。办不上的话，没办法，等下一列。