在焦虑的长夜中，这首诗总能让人切身的体会到当年苏轼老师的感受，时过境迁，来到我们所谓的现代化社会，又有多少人会有同样的情感？漫漫历史长河在浩瀚的宇宙里，也非常短暂，所以这首跨越了将近千年的诗，在现在看起来也是非常贴切，能够引起很多人的共鸣。
大家五一快乐，好久不见，失踪人口回归啦！这段时间接触游戏研发管理比较多，对游戏的行业发展、技术架构、研发模式等方面有了一些新的认识，毕竟自己曾经也是「游戏厅三王子」，曾经荣获「拳皇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 使用过程中更加得心应手。
众所周知，Git 是当前最流行的分布式版本控制系统，近两年由于 DevOps 的迅速发展，一切皆代码正在成为标准实践。而这一切，都需要有一个配置管理中心统一管控，Git 毫无疑问的成为了这个领域的宠儿。日常开发工作中，我们经常用不同方式去下载和上传代码到 Gitee，那么这背后是如何实现的呢，让我们一起来聊聊 Git 不同的传输协议以及具体的实现。
在开源理念日渐活跃的今天，越来越多的人开始投身于开源，贡献了越来越多的开源项目。而随着时间的推移，更多的人开始为开源项目添砖加瓦，为某一领域的开源项目贡献出自己的力量。贡献者的增多又给开源作者带来不少审核的压力，实际上投身开源的这些开源作者基本都是业余时间来做，并没有太多的时间投入在开源项目上。本文就为了解决这类场景，介绍下如何在 Gitee 上通过 Jenkins 来为自己的开源项目开启自动化协作，旨在将一些开源相关的工作自动化，留出更多的时间投身开源事业。
说起 PullRequest 相信大部分人都不会陌生，它是由 Github 推出的一种开源协作模式，由于 Gitlab 占据着企业内部私有部署的半壁江山，这种模式也更多的用在企业内部代码审核流程，也就是所谓的 CodeReview。其实还有很多企业和团队会选择 Gerrit 这个工具，Gerrit 提供的是 ChangeRequest 模式，这种模式更具有针对性，对代码审核的粒度也更细，近期有客户需求在 Gitee 上实现类似 ChangeRequest 的需求，所以针对两种模式做一个介绍，探讨两种模式的具体适用场景。
最近看到了一篇文章，细讲了各种分布式调度原理，其中加权轮询算法（Weighted Round-Robin）应该是离我们最近的一种方式了，Nginx 的 Upstream 就是用的这个算法，这个算法可以根据权重使得每个服务器能够均匀的负载请求，本篇主要就是来总结下使用这个算法以及 Go 内置的方法来实现一个简单的加权轮询的 HTTP 负载分发代理，并对负载分发及路由做一些延伸思考。
前面我们介绍了 Jenkins 相关的流水线以及可视化编辑流水线的 BlueOcean 插件，接下来我们主要通过一些实际的应用，来介绍下 Jenkins 在实际工作中的应用，同时也能够避免枯燥乏味的功能介绍，直接切入应用，这样来的比较有成就感。近期也是因为公司工作调整，突然间多了很多事，所以停更了一个月，晚上睡觉想起倍感羞愧，不敢睡觉，于是赶紧补上此篇博客来弥补内心的空缺 ;D
上篇中我们介绍了 Pipeline 的语法，也可以通过 Pipeline Editor 进行编辑，但是这些还不够，Jenkins 团队为了用户更方便的使用流水线，降低用户使用成本以及优化用户使用体验，推出了 BlueOcean，BlueOcean 是以插件的形式存在的，用官方的话说就是重新思考用户体验，它提供了一个更加灵活的流水线编辑器，允许你更加直观的进行流水线的定制，更加直观的观察到每一个步骤甚至每一个任务的运行状况。