我的项目背景

在一家公司做 DevOps 相干工作，很多年前试用了一些 Git 产品，但不满足咱们的流程须要。于是在业余时间开发了这个产品并在外部应用，饱受好评。之后开源，始终保护至今。可用于自建 Git 服务，自带看板和 CI/CD。

我的项目地址：https://github.com/theonedev/…

相比 GitHub/GitLab 有什么特点？

开箱即用的符号搜寻和跳转

尽管 IDE 也能够做这些事件，然而咱们常常须要切换到以前的 commit 搜寻（比方某个 issue 对应的 commit），这在 IDE 里须要切换工作环境有点麻烦，也有点慢，不如间接关上 onedev 搜寻不便。

这个性能应用 ANTLR 剖析支流语言的语法，并提取符号定义进行增量存储，速度快，占用空间小。目前反对 Java, JavaScript, C, C++, CSharp, Go, PHP, Python, CSS, SCSS, LESS and R。GitHub 前两年退出了这个性能，然而如同只是针对主分支；GitLab 须要在 CI 里做 LSIF 相干配置，比拟麻烦，并会占用大量空间。

在代码评审时也常常跳转去看某个符号的定义。

对仓库代码的正则表达式搜寻

能够切换到任意 commit，并进行正则表达式搜寻。仓库代码应用 Lucene 分词，并按需增量存储，正则表达式自身先进行分词进行粗略查问，而后在后果里再进行准确匹配来进步速度。

动态剖析后果间接标注在源码上，作为代码评审的辅助信息

当然 GitHub 有很多第三方工具能够做这个事件，但发现的问题都是显示在各自的网站上，与代码评审流程割裂开来了，使得一些流程很不不便，比方咱们有时须要在源码上对动态剖析发现的问题加评审阐明等等。另外这些第三方工具个别都须要额外收费。

Issue 字段和状态可定制，以及和 CI/CD 的深度集成

这里 GitHub/GitLab 的简略的 open/close 的状态齐全不能满足咱们的需要，特地是牵涉到客户创立的 issue 时。如果开发人员在 commit 代码时 close 相干 issue，客户失去告诉会认为这个问题曾经解决，于是会问咱们应该更新到哪个发行版；而如果在产品公布时 close 相干 issue，测试人员在拿到测试版时也很困扰，因为相干 issue 还是 open 状态，不晓得该测试哪些 issue。为解决这个问题，咱们定制了四个 issue 状态：open，committed，test ready 和 released。当开发人员 commit 代码时，相干 issue 主动迁徙到 committed 状态；当蕴含这些 commit 的代码被构建并部署到测试环境中时，相干 issue 主动迁徙到 test ready 状态，并告诉 QA，QA 能够在 issue 的详情页面里理解部署到了哪个测试环境；当测试通过创立发行版时，相干 issue 主动迁徙到 released 状态，并告诉客户，客户在 issue 的详情页里能够得悉关联的发行版。

弱小易用的 Commit/Issue/Build/Pull Request 查询语言

这个也是基于 ANTLR 做的，对语法规定进行预测来实现主动提醒。这样无需学习语法就能够间接进行简单查问，比方咱们客户常常做的事件就是在降级前查问以后版本和最新版本之间都有哪些改变等等。查问能够保留并订阅，这样合乎相干条件的事件产生时能够及时失去告诉。

全功能的 CI/CD，无需理解 Yaml 语法，上手非常简单

CI/CD 是花精力最多的局部了，尽管 CI/CD 的定义也是以 Yaml 文件的形式存储在仓库中，但提供了 UI 来生成该文件，用户无需理解任何相干语法即可进行配置。

在 Commit 页面能够间接运行 CI/CD 工作，使得 GitOps 来的更直观。灵便可定制的 CI/CD 选项页面让非开发人员也能够很容易的进行部署。

部署一个用于构建的集群及其不便，只需一个 helm 命令就能够部署到 Kubernetes 中，每个构建工作会作为 Pod 运行，同时反对 Windows 和 Linux；在没有 Kubernetes 的环境中，一行 docker 命令即可启动一个构建的 Agent，而且 Agent 免于保护，主动降级。

摒弃 Organization，将我的项目以树形构造组织以不便设置的继承

自从 GitHub 应用 Organization 后，仿佛所有相似的软件都采纳这种形式来组织我的项目了。这种形式对于面向公共服务的云平台而言可能比拟适合，但对于公司外部应用感觉没有太大必要。咱们的做法是将我的项目以树形构造组织，上级我的项目能够主动继承下级我的项目的设置，也能够按需笼罩。这使得大量我的项目的配置保护非常容易。

随时对代码进行标注和探讨，而不必依赖于 Pull Request

在浏览源码或者 Diff 时，能够对任意代码块即时发动探讨。探讨的内容将作为代码文档的一部分（即便预先代码改变甚至更名），不便其他人当前对代码进行浏览和了解。不同于其余的 Git 工具，代码 Comment 在侧边显示，防止割裂代码上下文，影响浏览。

另外每处探讨造成独自的主题，使相干的人很容易晓得哪里有新的改变或回复。

资源占用相比 GitHub/GitLab 小很多，速度快

集体应用的话，默认状况下一台 1 核 2G 的机器足够了，调整下 conf/wrapper.conf 里的内存设置，也能够跑在 1 核 1G 的机器上。比 Gitea/Gogs 的资源占用还是多的，不过如果 Gitea/Gogs 要做相似性能，受限于 Golang 的生态，可能要启动一些其余语言写的微服务（比方各种 Language Server，Elastic Search 等），最终资源耗费肯定不会小。

还有一个长处就是主服务能够运行在 Linux，Mac，Windows，FreeBSD 等多平台上，能够应用内置文件数据库，也能够充分利用公司现有资源连贯到 MySql/MariaDB/PostgreSQL/Oracle/SQL Server 等外置数据库。

其余特点诸如主动依据 Commit 历史举荐适合的代码评审人、markdown 编辑时同步滚动预览（不是简略的算滚动条百分比，而是依据上下文同步）、可定制的 issue 关联、粗疏的权限设置等就不一一赘叙了。

技术栈

不够时尚，从头到脚 Java 一把撸。不分前后端，所有代码在一个 Maven 我的项目中（40 万行代码左右）。应用 Wicket（预计很少人据说）把界面交互和后端逻辑封装在一个组件中，配置界面通过 Annotation 主动生成。依赖注射和插件体系基于 Guice。在 Eclipse 中启动我的项目大略耗时 20 秒，不过大部分工夫热部署，改变代码后间接刷新页面就能够看到改变。

谢谢关注，感兴趣的敌人点此五分钟教程（创立 react demo，并配置 CI）：
https://zhuanlan.zhihu.com/p/…