将被Git或OpenSSH调用。其他子命令可以帮助维护Gitea。 tests ：常用的测试函数 tests/integration ：集成测试，用于测试后端回归。 tests/e2e ：端到端测试，用于测试前端和后端的兼容性和视觉回归。 models ：包含由xorm用于构建数据库表的数据结构。它还包含查询和更新数据库的函数。应避免与其他 Gitea代码的依赖关系。在某些情况下，比如日志记录时可以例外。 重构的PR应尽快合并，不应被其他PR阻塞。 如果TOC没有异议，重构的PR可以在7天后由一名核心成员（非作者）批准后合并。 如果最终结果良好，容忍一些不完美/临时的步骤。 如果重构是必要的，容忍一些回归错误，并尽快修复错误。 重构指南 背景 重构建议 审查和合并建议 重构指南 - 290 - 本文档使用 书栈网 · BookStack.CN 构建 Gitea的本地化是通过我们的Crowdin项目进行的。

他们对新的系统制订了若干目标： • 速度 • 简单的设计 • 对非线性开发模式的强力支持（允许成千上万个并行开发的分支） • 完全分布式 • 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量） 自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。 它的速度飞快， 极其适合管理大项目，有着令人难以置信的非线性分支管理系统（参见 Git 分支）。 Git 之后，就可以合并入主干分支中，等待下一次的发布。 事实上我们刚才讨论的，是随着你的提交而不断右移的指针。 稳定分支的指针总是在提交历史中落后一大截， 而前沿分支的指针往往比较靠前。 图表 26. 趋于稳定分支的线性图 通常把他们想象成流水线（work silos）可能更好理解一点，那些经过测试考验的提交会被遴选到更加稳定的流 水线上去。 图表 27. 趋于稳定分支的流水线（“silo”）视图 82 你可以用这种方法维护不同层次的稳定性。 变基与拣选工作流 为了保持线性的提交历史，有些维护者更喜欢在 master 分支上对贡献过来的工作进行变基和拣选，而不是直 接将其合并。 当你完成了某个主题分支中的工作，并且决定要将其整合的时候，你可以在该分支中运行变基命 令， 在当前 master 分支（或者是 develop 等分支）的基础上重新构造修改。 如果结果理想的话，你可以快 进 master 分支，最后得到一个线性的项目提交历史。

他们对新的系统制订了 若干目标： 速度 简单的设计 对非线性开发模式的强力支持（允许成千上万个并行开发的分支） 完全分布式 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量） 自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着 初期设定的目标。 它的速度飞快，极其适合管理大项目，有着令人难以置信 的非线性分支管理系统（参见 Git 分支）。 GIT 以合并入主干分支中，等待下一次的发布。 事实上我们刚才讨论的，是随着你的提交而不断右移的指针。 稳定分支的指 针总是在提交历史中落后一大截，而前沿分支的指针往往比较靠前。 图表 26. 趋于稳定分支的线性图 通常把他们想象成流水线（work silos）可能更好理解一点，那些经过测试考 验的提交会被遴选到更加稳定的流水线上去。 图表 27. 趋于稳定分支的流水线（“silo”）视图 你可以用这种方法维护不同层次的稳定性。 变基与拣选工作流 为了保持线性的提交历史，有些维护者更喜欢在 master 分支上对贡献过来的 工作进行变基和拣选，而不是直接将其合并。 当你完成了某个主题分支中的 工作，并且决定要将其整合的时候，你可以在该分支中运行变基命令， 在当 前 master 分支（或者是 develop 等分支）的基础上重新构造修改。 如果结果 理想的话，你可以快进 master 分支，最后得到一个线性的项目提交历史。