Gitee 更新日志

Gitee 项目拓扑图 —— 密集恐惧症患者谨慎进入 2020-03-18

公司里有那么多人，那么多项目，那么多仓库，还有几个部门。他们之间的关系是怎样的？晕不晕？

我们换一种方式来展示这些对象之间的关系：

是不是更晕了？这就是典型的密集恐惧症啊！

这是开源中国的项目拓扑图，我们公司一百多号人，七百多个仓库，看起来就是密密麻麻如蜘蛛网般。

点击其中一个项目（如下图），这回要舒服多了吧？

这就是 Gitee 企业版新的小特性 —— 项目拓扑图，通过图的方式来展示项目、团队、成员、仓库之间的逻辑关系。

你可以进入 Gitee 企业版 -> 项目 -> 项目拓扑图查看。

更多 Gitee 企业版特性请前往：https://gitee.com/enterprises

代码质量管理利器 Gitee Scan 发布 2020-03-17

在项目开发的过程中，代码质量管理是非常重要的一个环节，项目中代码质量的高低直接影响着整个开发团队的工作效率。代码质量低会直接带来线上 Bug 频发、工作成果与工作时间不成正比、查找 Bug 困难等问题。

这些问题单纯的依靠开发后的人工测试是无法发现的，只能通过代码审查去发现和解决。进行代码审查时，除了严格执行代码规范、编写单元测试、必须的 Code Review、代码模块化等方法以外，有一件趁手的工具也是必不可少的。

Gitee 为了协助用户提高代码质量，进行完善的代码审查，推出了代码质量分析工具 Gitee Scan 。

依托于 Gitee 企业版的现有功能，Gitee Scan 能够通过扫描仓库内的代码，帮助开发团队找出其中的问题，尤其是一些不需要人工审查的低质量错误，帮助团队进行代码审查，从而提高代码质量。

Gitee Scan 可以同时从代码缺陷和代码规范两个方面对代码进行扫描，快速定位错误代码和漏洞的位置，帮助开发人员将更多精力放在解决问题而不是发现问题上。目前 Gitee Scan 支持的语言有 Java、Python、PHP、C、C++、JavaScript、Go 以及独立针对 Android 特性的扫描。

在使用 Gitee Scan 时，用户可以通过两种方式发起代码质量分析：

进入指定仓库中选择仓库分支发起全量扫描
开启新建 Pull Request 增量代码自动扫描

当开发人员想要对以前的代码进行错误检查时，可以选择进行全量扫描。全量扫描时，用户可以直接选择某个分支直接进行扫描操作并产出报告。报告中包含了缺陷报告及规范报告，在缺陷报告中，Gitee Scan 会通过 Bug、安全漏洞以及代码异味三个类别将问题分类，方便开发人员有针对性的修改。

如下图所示，报告中已经精准的定位到了错误代码的位置以及其可能的危险程度，开发人员直接进行修改即可。

在开发人员想要对后续产生的新代码进行错误检查时，可以选择进行增量扫描。Gitee Scan 增量扫描与全量扫描原理相同，但增量扫描更加自动化。开启增量扫描的开关后，企业内的所有分支在接受 Pull Request 前都会经过 Gitee Scan 的自动扫描并产出报告，每提交一次 Pull Request 后都会对提交的代码进行一次自动扫描。

测试结果表明，针对同一份代码，Gitee Scan 所扫描出的漏洞数量比同类型产品 SonarQube 多出 41.7%，并且 Gitee Scan 扫描后提供了代码评级及代码规范报告，用户可以对代码质量有更直观的了解。

在后续的更新中，Giee Scan 会增加更多语言的支持以及更加深度的扫描能力，并且后续计划增加基于 CVE 的依赖项漏洞扫描，进一步帮助用户提升研发质量和效率。

*Gitee Scan 已对 Gitee 企业版付费客户开放功能

了解 Gitee 企业版更多功能，请点击下面的链接：https://gitee.com/enterprises

Gitee 轻量级 PR —— 参与开源贡献，原来就是举手之劳的事 2020-03-13

Github 发明了 Pull Requests ，让全球范围内的开源协作变得如此简单。任何人不需要联系作者，只需简单四步即可提交贡献代码给项目：

Fork 主仓库到自己账号成为副本仓库
在副本仓库完成代码贡献（添加、删除、修改代码等等）
将副本修改的内容给主仓库提交 PR ( Pull Requests )
作者审核你提交的代码，并决定是否合并

这种简单的协作模式让开源软件发展非常非常快速。

但参与开源贡献并非一件简单的事，你必须对项目有着非常深入了解。可有时候我们可能只是想帮作者纠正一些文档的错误，或者一些不易发掘的代码错误等等。那么这个 Pull Requests 的操作就有点复杂，会因此打消很多人贡献的想法。

为了降低开源贡献的门槛，Gitee 推出了 轻量级PR 的功能。

具体使用流程如下：

1. 打开任意的开源项目，例如 https://gitee.com/ld/J2Cache

2. 点击任何你发现问题的文件，并直接进入文件编辑（如下图）

3. 完成你想要修改的内容，输入修改的说明，点击“提交审核”按钮

4. 完事了，接下来就等着作者审核

这时作者会收到一个 PR 的信息，按照普通的 PR 进行审核即可。
输入图片说明

Gitee 的轻量级 PR 在 Gitee IDE 中也是支持的，你可以通过仓库页面的 Web IDE 进入，修改多个文件并提交轻量级PR，有兴趣的朋友可以试试看。

去年微软全面拥抱的“内源”，到底是什么？ 2020-03-06

2000 年，Tim O’Reilly 首次提出了 InnerSource 的概念，也就是内部开源（以下简称内源）。虽然这个概念已经提出了二十年，但在国内还是个较为陌生的事物。相对于内源，大家可能更加熟悉的是开源（Open Source），这种将软件源代码公开的发布模式已经成就了许多优秀的软件和开发者。而内源则是将开源的模式引入至公司或组织内，让开发人员们可以在内部施行开源的同时开发企业专有的软件。

为什么要推行内源

增加代码复用，提高产品质量

增加组件和代码的复用，也可以说是减少组件和代码的重复开发。大家都清楚，重复造轮子可以说是最没有意义的一件事，而内源可以有效地消除这个麻烦。

通俗一点讲，团队 A 在开发时需要一个新功能，而这个功能团队 B 恰好之前做过，那么这时团队 A 就可以直接在内源仓库中将团队 B 的代码直接拿来使用，甚至还会交还给团队 B 一个质量更好的版本，就像 Linus 法则所说的：只要有足够多的眼球，就可以让所有 Bug 浮现。

但如果没有这个内源仓库的话，团队 A 只能重新开发这个功能。这个过程中所浪费的不仅是时间和成本，甚至还有更重要的——商业机遇。

加速知识共享，提升开发人员能力

如果开发人员处于相对孤立的环境，测试人员也仅限于自己的小团队，在 Bug 响应和解决问题的资源方面，当然会受到各种限制。如果这时团队拥有更多不同经验和观点的外部成员，他们可以找到并解决多少个问题？这会对产品的质量产生什么影响？答案当然是显而易见的。

而作为管理者，与你合作的开发人员都是获得了你认可的优秀的伙伴，但他们可能只与三五个人或十来人一起工作并互相学习。如果他们能和二十或三十个，或更多优秀的开发者一起工作，他们能够在知识共享的同时相互学习，提升自己的能力，自然能够带来产品质量的进步。

开放带来的创新

开发人员通常都是聪明绝顶的，让几十名甚至上百名聪明绝顶的开发人员在一起工作，这些头脑之间摩擦出来的火花能够为企业带来更多意想不到的惊喜，一个更炫酷的新功能甚至一个全新的产品都是有可能的。但如果在他们中间建立起各种无形的墙，这种创新能力无疑会大打折扣。

内源的发展现状

国外许多大厂也已经开始进行自己的内源实践，比如谷歌只有一个代码仓库，由来自世界各国数十个办事处的数万名开发人员共享，微软也在 2019 年宣布全面拥抱内源。更有影响力的是 PayPal 于 2015 年牵头成立的 InnerSource Commons 社区，他们现已为近百家公司、学术机构和政府机构提供支持和联系。

就国内而言，虽然仍旧是一个新鲜事物，但国内的大厂也都开始积极地推行内源。拥有两万多开发人员的腾讯自 2012 年就开始从下到上做内部开源，现已经能做到 65% 的项目内部开源。百度的内源推进工作也已经有了一些成果，如在百度内部应用很广的开源深度学习平台 PaddlePaddle 和 PHP 开发框架 ODP。就 ODP 项目来说，由于项目人力较少，无法面对较多的需求，于是在 2016 年开始内部开源，内源一年后，超过 200 名开发者加入到项目中做贡献，并且有超过 100 个 Patch 被合入。

可以说，内源在国内已经初见端倪，后面只会有更多的企业拥抱内源。