玩轉 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.25 或更高版本是必須的。Gitea 使用 gofmt 來
格式化源程式碼。然而，gofmt 的結果可能因 go 的版本而有差異。因此推薦安裝我們持續整合使用
的 Go 版本。截至上次更新，Go 版本應該是 1.25。
安裝 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。