• 日拱一卒
    2019-09-13
    看完这篇后,最大的感受就是Git是个宝库,之前对它的使用还停留在表面,我要去找本书系统学习一下。

    作者回复: Git的却很强大,很方便。确实也需要投入时间学习。我2010年初始Git的时候,找一个Git老手讨教,他非常热心地给我讲了一个半小时,我还是迷迷糊糊。不过现在想起来还是很感激他 :)

    这个链接是一个有趣的图形化Git学习工具。你可以看看:http://git-school.github.io/visualizing-git/#cherry-pick

    
     6
  • phobal
    2019-09-07
    像 Facebook 这种主干(master)开发模式,每个人的代码每天都会合入到 master,实际中经常会有这样的情况:A、B 两个 feature 同时在进行,但上线时间不同,A 先上,那基于这种模式,A 上的话就会带入 B 的代码,难道 A 上的时候再基于上一个稳定版本 tag 再 cheery-pick A 的所有功能代码到测试分支?

    作者回复: 如果B的功能还没有准备好给用户使用,可以使用功能开关隐藏。

    
     2
  • Johnson
    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
  • GeekJ
    2020-02-02
    从上面文章中获取,您的cherry-pick 策略都是在master上进行修复,然后cherry-pick 至周部署分支或热修复分支。
    针对这个场景,我有以下几个问题
    1. master分支每天有很多提交,其分支代码与周部署分支&热修复分支很大可能已经不一致了,如何保证cherry-pick质量?为什么不是从待发布分支 cherry-pick 至 master 分支呢?
    2. cherry-pick 操作是自动化,还是手动的?
    
    
  • 菜头
    2019-12-27
    facebook 的原子化提交这块,开发是以什么标准拆分,确保原子性的。老师能否帮忙介绍下。谢谢

    作者回复: 几个标准:
    1. 提交不要超过一个功能。如果是bug fix的话可以有几个类似的fix放到一起(因为提交太小也不好)。
    2. 如果功能较大,提交应该是一个功能的子功能
    3. 这个提交需要能够入master库后不会break master。也就是说,该提交在入master之后,上可以从这个提交的位置发布一个产品。当然可能会有Bug,但是不能出现功能不能用的情况。要么功能实现完成,要么用户看不到。

    另外大小上来说,并没有严格规定多少文件多少行。但是要让代码审查者审查起来不能太困难。

    
    
  • tk
    2019-11-20
    有没有toB的分支模型建议,多客户,核心功能相同,但是多个客户可能有不同的功能集合或者定制

    作者回复: 会持续开发新的功能吗?如果可以的话,推荐一个分支,使用功能开关控制。如果不行,就只能使用多个发布分支。

    
    
  • Robin
    2019-11-15
    facebook 的 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,测试左移,测试右移都是比较有效的办法。后面的文章,会有比较详细的介绍,敬请期待。

    
    
  • XUN
    2019-09-07
    老师能不能讲讲移动端的开发管理,看了几篇都是后端的集成和发布流程

    作者回复: 前边描述的各种原则,在移动端后端都是一致的,比如说持续开发,持续集成,持续交付等。

    就拿在iOS的Facebook APP 的开发做例子。首先他们也是采用单主干的开发分支模式。要求代码提交的原子性,以及master分支上代码的线性历史。在持续集成方面。他们也是使用的Phabricator作为历程和质量控制中心,进行各种各样的代码入库前检查。在持续交付方面。他们也是采用了和后端类似的方式,每隔一定时间进行一次全量的构建和验证。

    当然,也会有一些差别。我在后面的文章中会找机会详细描述。

    感谢你的提问!

    
    
  • 囧囧冰淇淋
    2019-09-07
    看到今天,感觉研发和代码越来越有趣了XD

    作者回复: 对大家有用,让大家觉研发有趣,感觉写文章越来越有趣了XD

    
    
  • 李双
    2019-09-06
    各种分支管理策略,学习!问下,基于base开发的这种方式,是不是根据时间线,截止某一时间点(或者某个版本号之前的),代码验证过了,就可以上线了,而不是根据业务功能的先后紧急!

    作者回复: 对的。这种方式是发布周期与功能解耦。版本火车一列一列发出去。功能开发者自己决定把commit搭乘哪一列。办不上的话,没办法,等下一列。

    
    
我们在线,来聊聊吧