在焦虑的长夜中，这首诗总能让人切身的体会到当年苏轼老师的感受，时过境迁，来到我们所谓的现代化社会，又有多少人会有同样的情感？漫漫历史长河在浩瀚的宇宙里，也非常短暂，所以这首跨越了将近千年的诗，在现在看起来也是非常贴切，能够引起很多人的共鸣。

大家五一快乐，好久不见，失踪人口回归啦！这段时间接触游戏研发管理比较多，对游戏的行业发展、技术架构、研发模式等方面有了一些新的认识，毕竟自己曾经也是「游戏厅三王子」，曾经荣获「拳皇97战神」、「西游&三国一币通关王」等称号（手动狗头），当年玩游戏的时候就对游戏的制作有很多疑惑，最近总算是有了一定的了解了，所以写写分享给大家。

前段时间 Git 发布正式版本 2.33.0 遇到一个客户端与服务端不兼容的一个问题，在排查问题的过程中又一次用到了 Git bisect 命令，解决问题的同时结合近期的一些认知，又刷新了自己对 bisect 命令的认识，bisect 可以结合一些场景发挥其妙用，借此分享下 bisect 命令以及 bisect 命令的一些其它使用方式的思考。

企业从内部开源到外部开源，是没有办法完全复制企业内源那套玩法的，虽然二者有很多共性，但毕竟参与者从企业内部员工直接扩大到了整个社会，在协作方面还是有不少差异的。这篇文章主要是基于对 Huawei 在 Gitee 上开源项目的协作方式，一步一步分析开源软件的协作模式，以及一些企业参与开源需要注意的事项。

无论是工作还是生活，方方面面无不体现同理心作用，绝大多数情况下的事情，拥有同理心都会好办很多。无论是什么场景，同理心总有它奇妙的作用之处，每一个人都应该尝试多去换位思考，这个世界才会变的更加美好 ;D

去年写过一篇文章《浅谈 Pull Request 与 Change Request 研发协作模式》，详细介绍了 PR Flow 以及 CR Flow 的区别，文末有说到 Gitee 应该提供推送分支自动创建评审的这项改进，刚好近期也听到很多关于平台支持 CR Flow 的声音，而且在不少客户内部也有类似需求，毕竟这个需求可以解放开发者的一部分精力，对于追求研发效能的当下，自然是一个不错的功能点，另外对于 Gerrit 转到 Gitee 的用户，也是一个平滑的过渡方案。所以写下这篇文章，探讨一下支持 CR Flow 平台的产品实现，并对 CR Flow 实现的底层原理做了一些实验性的工作，以供参阅。

码云 Gitee 自2013年推出以来，每年的数据量都是倍增的，截止到2021年3月份，Gitee 上已经有了600万+的开发者，超1500万的仓库，成为了国内首屈一指的研发协作平台。在数据日益增长的过程中，Gitee 的架构也是经过了数个迭代，才能支撑起目前的数据量级。我曾在不少的大会上分享过 Gitee 的架构，也和很多有类似场景的同学一起讨论过，偶然被问起有没有专门的文章来介绍 Gitee 架构的，所以难得假期有时间，将此主题整理成文，以供大家参阅。

无意翻出这篇写于两年前的手稿，当时交付的几家私有云大客户以及公有云客户均频繁遇到此问题，虽然现象千奇百怪，但是无非是错误的操作导致的代码丢失，秉承着开放、自由、分享的开源精神，把相关的错误操作整理出来并加以说明，对于新老用户都是一种引导，不仅可以避免给团队带来麻烦，也使自己能够更好的理解 Git 的一些运作方式，所以整理成文，希望能够帮助到有需要的人，尤其是公司内部研发流程的培训上，更应该关注这一类误操作的普及和说明，避免「不了解」给团队带来的麻烦。

Git 是目前最流行的版本控制系统，从本地开发到生产部署，我们每天都在使用 Git 进行我们的版本控制，除了日常使用的命令之外，如果想要对 Git 有更深一步的了解，那么研究下 Git 的底层存储原理将会对理解 Git 及其使用非常有帮助，就算你不是一个 Git 开发者，也推荐你了解下 Git 的底层原理，你会对 Git 的强大有一个全新的认识，并且将会在日常的 Git 使用过程中更加得心应手。