如何用 Gitea 玩转代码协作Pull Request、Issue 跟踪与 Kanban 看板完整指南【免费下载链接】giteaGit with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD项目地址: https://gitcode.com/GitHub_Trending/gi/giteaGiteaGit with a cup of tea是一款自托管的一站式软件开发服务内置Git 托管、代码审查Pull Request、Issue 跟踪、项目 Kanban 看板、团队协作、包注册与 CI/CD能力。本文面向新手带你用 3 个核心功能搭建完整的团队协作闭环从建 Issue 立项到 PR 评审合并再到看板跟踪进度。1. 为什么选 Gitea一个平台搞定代码协作能力说明 自托管一个二进制文件即可部署数据完全在自己服务器 代码审查Pull Request 支持行级评论、批准/拒绝、合并策略 Issue 跟踪标签、里程碑、指派、依赖关系一应俱全 Kanban 看板仓库级项目看板Issue 可拖拽流转 CI/CD兼容 GitHub Actions 工作流Gitea 由 Go 编写支持 Linux、macOS、Windows 等几乎所有平台。若你想从源码构建体验可以克隆仓库git clone https://gitcode.com/GitHub_Trending/gi/gitea构建后执行./gitea web即可启动详见官方示例配置 custom/conf/app.example.ini。2. Issue 跟踪实战让每个任务都有归属2.1 创建 Issue 并打上标签进入仓库页面后点击Issues标签即可创建 Issue。建议为团队建立固定的标签体系bug缺陷、feature功能需求、good first issue新人友好用里程碑Milestone把 Issue 归入版本例如v1.0、v1.1发布时一眼看出完成度Issue 的后端模型集中在 models/issues/ 目录标签、里程碑、指派、锁帖等功能分别对应独立文件例如标签逻辑在 models/issues/label.go。2.2 指派人与依赖关系指派Assign在 Issue 右侧边栏把任务分配给具体成员被指派者会收到通知依赖Depends onGitea 支持 Issue 间声明依赖前置任务未关闭时看板会提示阻塞非常适合梳理先做 A 再做 B的链路Issue 的业务操作评论、状态变更、指派等由 services/issue/ 提供例如状态变更见 services/issue/status.go。3. Pull Request 实战代码评审的标准姿势3.1 从分支到 PR 的四步流程从main拉出特性分支git checkout -b feat-login提交并推送你的改动在仓库的Pull Requests页点击New Pull Request填写标题与描述勾选Squash提交 PR 小技巧在 PR 描述中写上Closes #12合并后会自动关闭第 12 号 Issue——这是把 Issue 跟踪与代码变更连起来的关键动作。3.2 评审行级评论与批准机制评审者在Files changed页可以在任意一行旁发起行级评论支持多人讨论发起 Review 时选择Approve批准、Request Changes要求修改或Comment仅评论评审与合并检查的实现位于 services/pull/其中 services/pull/review.go 处理评审请求services/pull/check.go 负责合并前检查。3.3 四种合并方式怎么选合并策略效果适用场景Merge Commit保留完整分支历史大型功能分支Squash推荐多个提交压缩为一个小步快跑的日常 PRRebase变基后线性历史追求干净 git log 的团队Fast-forward Only仅当无分叉时快进严格保持主干线性四种策略分别实现在 services/pull/merge_merge.go、services/pull/merge_squash.go、services/pull/merge_rebase.go、services/pull/merge_ff_only.go。3.4 保护分支给主干上保险在仓库设置 → 分支中把main设为保护分支可强制要求必须通过 CI 检查才能合并必须至少 1 人批准评审合并前要求分支为最新防止冲突这从机制上杜绝了未经评审直接推主干的乱象。4. Kanban 看板实战进度一目了然4.1 创建项目看板进入仓库 → Projects项目点击New Project创建看板。看板视图模板见 templates/repo/projects/view.tmpl。新建时你可以选择模板Template快速套用团队预设的列结构自由增删列例如Backlog → In Progress → Review → Done4.2 拖拽流转 Issue看板支持把仓库中的 Issue 直接拖入对应列在 Issue 列表勾选要加入看板的条目拖拽卡片调整列即代表状态变更卡片上直接显示标题、标签与指派人看板的前端拖拽交互由 web_src/js/features/repo-projects.ts 驱动Issue 与看板列的关联逻辑在 services/projects/issue.go列与卡片的数据模型定义于 models/project/如 models/project/column.go。⚠️ 注意看板卡片是视图而非副本——在看板上移动卡片Issue 本身的状态不变但 Issue 关闭后卡片会进入已归档区域。5. 三件套联动一套标准协作工作流把三个功能串起来就是团队的日常节奏① 建 Issue 立项并指派 ↓ ② 开发分支 → 提 PR描述中 Closes #N ↓ ③ 评审 CI 检查通过 → Squash 合并 ↓ ④ 看板卡片拖到 Done归档版本每个迭代初用看板Backlog列收集需求每日站会扫一眼看板各列卡片数量即可掌握阻塞点每个版本末检查里程碑完成率发布后归档路由层面看板与 Issue/PR 的入口分别在 routers/web/repo/projects.go、routers/web/repo/issue.go 和 routers/web/repo/pull.go感兴趣可以顺着这些文件了解实现细节。6. 新手常见 3 个问题Q1PR 和直接 Push 有什么区别PR 强制走评审 CI关卡且合并历史可追溯直接 Push 会绕过所有检查因此主干应始终保护、只通过 PR 进入。Q2Issue 和看板列的状态会互相同步吗看板负责流转视图Issue 的Open/Closed状态才是数据源。建议团队约定卡片拖到Done列时同步关闭 Issue。Q3小团队值得配这么多规则吗建议渐进式启用先开main分支保护 Squash 合并再逐步加上必须评审与看板流程避免一开始规则过重劝退新成员。总结Gitea 把Pull Request 代码评审、Issue 跟踪、Kanban 看板装进了一个轻量级的自托管平台Issue 负责立项与拆解PR 保障代码质量看板让进度透明。从git clone部署到保护分支配置一两个小时即可跑通全流程——数据在自己手里协作流程自然成型。【免费下载链接】giteaGit with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD项目地址: https://gitcode.com/GitHub_Trending/gi/gitea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考