玩转 Gitea
快速入门
要获得快速工作的开发环境，您可以使用 Gitpod。
安裝 Golang
您需要 安裝 go 並设置您的 go 环境。
接下来，使用 npm 安裝 Node.js ，这是构建 JavaScript 和 CSS 文件的必要工具。最低支持的 Node.js 版本是 22 並且推荐使用最新的 LTS 版本。
注意 ：当執行需要外部工具的 make 任务时，比如
make watch-backend，Gitea 会自动下载並构建这些必要的组件。為了能够使用这些，你必須
将 "$GOPATH"/bin 目錄加入到可執行路径上。如果你不把 go bin 目錄添加到可執行路径你必須手动
指定可執行程序路径。
注意 2 ：Go 版本 1.24 或更高版本是必須的。Gitea 使用 gofmt 来
格式化源代码。然而，gofmt 的结果可能因 go 的版本而有差异。因此推荐安裝我们持续集成使用
的 Go 版本。截至上次更新，Go 版本應該是 1.24。
安裝 Make
Gitea 大量使用 Make 来自动化任务和改進开发。本指南涵盖了如何安裝 Make。
在 Linux 上
使用包管理器安裝。
在 Ubuntu/Debian 上：
sudo apt-get install make
在 Fedora/RHEL/CentOS 上：
sudo yum install make
在 Windows 上
Make 的这三个发行版都可以在 Windows 上运行：
- 單个二進制构建。复制到某处並添加到
PATH。 - MinGW-w64 / MSYS2。
- Chocolatey 包管理器。运行
choco install make
注意 ：如果您尝试在 Windows 命令提示符下使用 make 進行构建，您可能会遇到问题。建议使用上述提示（Git bash 或 MinGW），但是如果您只有命令提示符（或可能是 PowerShell），则可以使用 set 命令，例如 set TAGS=bindata。
下载並克隆 Gitea 源代码
获取源代码的推荐方法是使用 git clone。
git clone https://github.com/go-gitea/gitea
（自从 go modules 出現后，不再需要构建 go 项目从 $GOPATH 中获取，因此不再推荐使用 go get 方法。）
派生 Gitea
如上所述下载主要的 Gitea 源代码。然后，派生 Gitea 存放庫， 並為您的本地存放庫切换 git 远程源，或添加另一个远程源：
# 将原来的 Gitea origin 重命名為 upstream
git remote rename origin upstream
git remote add origin "git@github.com:$GITHUB_USERNAME/gitea.git"
git fetch --all --prune
或者：
# 為我们的 fork 添加新的远程
git remote add "$FORK_NAME" "git@github.com:$GITHUB_USERNAME/gitea.git"
git fetch --all --prune
為了能够建立合並請求，應将分叉存儲库添加為 Gitea 本地存放庫的远程，否则無法推送更改。
构建 Gitea（基本）
从源代码构建的最简單推荐方法是：
TAGS="bindata sqlite sqlite_unlock_notify" make build
build 目标将同时執行 frontend 和 backend 子目标。如果存在 bindata 標籤，资源文件将被编译成二進制文件。建议在進行前端开发时省略 bindata 標籤，以便实时反映更改。
有关所有可用的 make 目标，請参阅 make help。另請参阅 .drone.yml 以了解我们的持续集成是如何工作的。
持续构建
要在源文件更改时运行並持续构建：
# 對於前端和后端
make watch
# 或者：只看前端文件（html/js/css）
make watch-frontend
# 或者：只看后端文件 (go)
make watch-backend
在 macOS 上，监视所有后端源文件可能会达到默认的打开文件限制，这可以通過当前 shell 的 ulimit -n 12288 或所有未来 shell 的 shell 启动文件来增加。
格式化、代码分析和拼写检查
我们的持续集成将拒绝未通過代码检查（包括格式检查、代码分析和拼写检查）的 PR。
你應該格式化你的代码：
make fmt
並检查源代码：
# lint 前端和后端代码
make lint
# 僅 lint 后端代码
make lint-backend
注意 ：gofmt 的结果取决于 go 的版本。您應該运行与持续集成相同的 go 版本。
处理 JS 和 CSS
前端开发應遵循 Guidelines for Frontend Development。
要使用前端资源构建，請使用上面提到的“watch-frontend”目标或只构建一次：
make build && ./gitea
在提交之前，确保 linters 通過：
make lint-frontend
配置本地 ElasticSearch 实例
使用 docker 启动本地 ElasticSearch 实例：
mkdir -p $(pwd) /data/elasticsearch
sudo chown -R 1000:1000 $(pwd) /data/elasticsearch
docker run --rm --memory= "4g" -p 127.0.0.1:9200:9200 -p 127.0.0.1:9300:9300 -e "discovery.type=single-node" -v "$(pwd)/data /elasticsearch:/usr/share/elasticsearch/data" docker.elastic.co/elasticsearch/elasticsearch:7.16.3
配置app.ini：
[indexer]
ISSUE_INDEXER_TYPE = elasticsearch
ISSUE_INDEXER_CONN_STR = http://elastic:changeme@localhost:9200
REPO_INDEXER_ENABLED = true
REPO_INDEXER_TYPE = elasticsearch
REPO_INDEXER_CONN_STR = http://elastic:changeme@localhost:9200
构建和添加 SVGs
SVG 图标是使用 make svg 命令构建的，該命令将图标资源编译到输出目錄 public/assets/img/svg 中。可以在 web_src/svg 目錄中添加自定义图标。
构建 Logo
Gitea Logo 的 PNG 和 SVG 版本是使用 TAGS="gitea" make generate-images 目标从單个 SVG 源文件 assets/logo.svg 构建的。要运行它，Node.js 和 npm 必須可用。
通過更新 assets/logo.svg 並运行 make generate-images，同样的過程也可用于从 SVG 源文件生成自定义 Logo PNG。忽略 gitea 编译選项将僅更新使用者指定的 LOGO 文件。
更新 API
建立新的 API 路由或修改現有的 API 路由时，您必須 更新和/或建立 Swagger 这些使用 go-swagger 评论的文檔。 规范中描述了这些注释的结构。 如果您想了解更多有关 Swagger 结构的信息，可以查看 Swagger 2.0 文檔 或与添加新 API 端点的先前 PR 進行比较，例如 PR #5483
您應該注意不要破坏下游使用者依赖的 API。在稳定的 API 上，一般来说添加是可以接受的，但删除 或对 API 進行根本性更改将会被拒绝。
建立或更改 API 端点后，請用以下命令重新生成 Swagger 文檔：
make generate-swagger
您應該驗證生成的 Swagger 文件：
make swagger-validate
您應該提交更改后的 swagger JSON 文件。持续集成服务器将使用以下方法检查是否已完成：
make swagger-check
注意 ：請注意，您應該使用 Swagger 2.0 文檔，而不是 OpenAPI 3 文檔。
建立新的配置選项
建立新的配置選项时，将它们添加到 modules/setting 的对應文件。您應該将信息添加到 custom/conf/app.ini
並到配置备忘單
在 docs/content/doc/advanced/config-cheat-sheet.zh-tw.md 中找到
更改 Logo
更改 Gitea Logo SVG 时，您将需要运行並提交结果的：
make generate-images
这将建立必要的 Gitea 图标和其他图标。
数据库迁移
如果您对数据库中的任何数据库持久结构進行重大更改
models/ 目錄，您将需要進行新的迁移。可以找到这些
在 models/migrations/ 中。您可以确保您的迁移适用于主要
数据库類型使用：
make test-sqlite-migration # 将 SQLite 切换為适当的数据库
测试
Gitea 运行两种類型的测试：單元测试和集成测试。
單元测试
go test 系统中的*_test.go 涵盖了單元测试。
您可以设置环境变量 GITEA_UNIT_TESTS_LOG_SQL=1 以在详细模式下运行测试时显示所有 SQL 语句（即设置GOTESTFLAGS=-v 时）。
TAGS="bindata sqlite sqlite_unlock_notify" make test # Runs the unit tests
集成测试
單元测试不会也不能完全單独测试 Gitea。因此，我们编写了集成测试；但是，这些依赖于数据库。
TAGS="bindata sqlite sqlite_unlock_notify" make build test-sqlite
将在 SQLite 环境中运行集成测试。集成测试需要安裝 git lfs。其他数据库测试可用，但
可能需要适應当地环境。
看看 tests/integration/README.md 有关更多信息以及如何运行單个测试。
测试 PR
我们的持续集成将测试代码是否通過了單元测试，並且所有支持的数据库都将在 Docker 环境中通過集成测试。 還将测试从几个最新版本的 Gitea 迁移。
請在 PR 中附带提交适当的單元测试和集成测试。
网站文檔
該网站的文檔位于 docs/ 中。如果你改变了文檔内容，你可以使用以下测试方法進行持续集成：
make lint-md
Visual Studio Code
contrib/ide/vscode 中為 Visual Studio Code 提供了 launch.json 和 tasks.json。查看
contrib/ide/README.md 了解更多信息。
Goland
單擊 /main.go 中函数 func main() 上的 Run Application 箭头
可以快速启动一个可调试的 Gitea 实例。
Run/Debug Configuration 中的 Output Directory 必須设置為
gitea 项目目錄（包含 main.go 和 go.mod），
否则，启动实例的工作目錄是 GoLand 的临时目錄
並防止 Gitea 在开发环境中加载动态资源（例如：模板）。
要在 GoLand 中使用 SQLite 运行單元测试，請设置 -tags sqlite,sqlite_unlock_notify
在 运行/调试配置 的 Go 工具參數 中。
提交 PR
对更改感到满意后，将它们推送並打开拉取請求。它建议您允许 Gitea Managers 和 Owners 修改您的 PR 分支，因為我们需要在合並之前将其更新為 main 和/或可能是能够直接帮助解决问题。
任何 PR 都需要 Gitea 维护者的两次批准，並且需要通過持续集成。看看我们的 CONTRIBUTING.md 文檔。
如果您需要更多帮助，請访问 Discord #Develop 频道 並在那里聊天。
現在，您已准备好 Hacking Gitea。