想写主干开发，因为这已经成了习惯，每天坚持写一些东西，尽量写一些思考。
正巧碰上偶像刘德华40周年抖音直播，从八点半开始，一直看到结束，看到八千多万的参与人数。
挺感动的，40年如一日，对于华仔来说，又是平常的一天。
主干开发要求高不高，高，很高，对个人，对团队，对管理，要求都高。
难不难，难，很难，改变大家的习惯难，让大家理解主干开发的思想难，让团队坚持主干开发，不走形，更难。
但就像今天偶像的直播主题一样，如果这就是平常的一天，一如既往的优秀，有什么事情还能阻挡我们的脚步呢！
挺开心的，不用在分支之间切来切去，也不用到最后解决各种冲突，基本上每天都有代码提交到主干上，并且代码库随时处于发布状态。
刚开始接触的时候，感觉有点束手束脚，因为多了很多需要了解的地方。
比如提交流程，提交前会在本地自动触发单元测试，只有通过了本地测试，才能提交成功。
要关心流水线状态，提交前要看流水线状态是不是健康的，通常绿色代表健康，只有绿色的时候，才能提交，并且要先拉取最新代码，再提交。 也会有冲突，但冲突不是那么剧烈，完全在可接受范围内，因为提交的量不大。 如果是红的，也就是说出错了，吼一嗓子，通常有声音会回复你说，正在修。
要控制好节奏，为了让流水线一直处于健康状态，通常在下班前不会大量提交代码，因为如果出现错误，就需要立刻修复，因为流水线红了不过夜的传统。 那会不会一天都不提交代码，这也不会，因为提交的越晚，你所面对的冲突可能性会越大，这样又是另一种痛苦。 所以在有pair的保证下，大家一起设定好节奏，上午集中注意力在昨天的代码走查修改，并最小步骤提交，下午尽量在4点前完成一张卡。 剩下的时间要么休息一下，要么捡下一张卡，了解上下文，做好开卡准备。 或者看一看其它小伙伴有没有什么需要支持的地方。 再就是干脆放松一下，和团队一起聊聊天，喝喝茶，等等。
总的感觉就是，主干开发能激活大家的积极性，同时对团队的代码工程实践有提出更高的要求，会有一个适应的过程，但最后的结果往往是多赢。
主干开发最大的好处就是保持主干代码处于随时可以布状态。
达到这种状态并不是一件轻松的事情，但一旦达到了又是件成就感满满的事情。
怎么让一个团队打造出好的氛围，来帮助实现主干开发呢？
这就像营造一个爱学习的氛围，大家要爱学习，会学习，还能坚持学习。
爱学习就像是一种价值导向，我们在这个环境里，以爱学习的人为榜样。
鼓励会学习的人，积极分享，乐于分享，不仅要善于发现这样的人，还要保护好这样的人。
最后就是坚持学习，一旦入了门，就要去思考，如何帮助大家找到坚持下去的动力。
主干开发也一样。
如何找到选择相信主干开发的人，如果暂时没有，就需要培养出这样的人。 这对团队里较有经验的人有较高的要求，你不仅要自己相信，还需要让别人接受并相信。
一旦发现有的人很有潜力，这时就需要鼓励TA影响到更多的人，如何扩大影响力，让更多的人加入其中。
最后整体氛围趋于成熟时，如何用较完整的体制让大家自然地坚持做团队认为对的事情，也是打造闭环的关键。
最容易想到的就是PR（Pull Request）了，在GitHub上主推的模式。 因为开源，代码的传播速率大大增加了，全世界的程序员都有机会看到你的代码，用到你的代码，可能用起来不是那么顺手，自然会加一些功能。 也有可能在使用的过程中有一些bug，顺手改了，俗话说得好，投之以桃，报之以李，那我就也为开源做份贡献吧。 提个PR，也为后人栽树乘凉，让善意码码相传。 这时候如果是主干开发，就不太现实，因为大家都不认识，很难让全世界的人都遵守最佳实践。 并不是大家刻意不去这样做，而是总有在信息表达，和传递上的偏差。 如果要做到主干开发，也不是没有办法，那就要对代码的自动化程序提出很高的要求了。 将走查PR代码的手动流程自动化，尽可能抽象出走查的流程和重点。
还有一种比较常见的场景就是分工协作，大家将模块都分好，约定好接口，然后独立开发。 这时候大家都在自己的开发分支上开发自己的模块，最后合并、联调。 这种模式好在职责清晰，我只需要专注在分给我的这一块就行了，大家八仙过海，各显神通。 坏其实也坏在这，代码在合并的时候往往会出现很多问题，合作起来往往没那么愉快。 如果有人说也有全是高手的㔹队，动作整齐划一，无缝衔接，理论上确实有，但实际工作中基本没看见过。
不管是分支开发还是主干开发，都是团队协作开发，并没有谁强过谁。 因为我个人始终觉得代码研发是一件创造型的工作，所谓文无第一，我们更希望看到的是百家争鸣。