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

大家五一快乐,好久不见,失踪人口回归啦!这段时间接触游戏研发管理比较多,对游戏的行业发展、技术架构、研发模式等方面有了一些新的认识,毕竟自己曾经也是「游戏厅三王子」,曾经荣获「拳皇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 使用过程中更加得心应手。