Docker 安装 在 Kubernetes 中安装 Gitea 在云服务器中安装 Gitea 从旧版 Gitea 升级 从 Gogs 升级 管理 Gitea 命令行 环境变量清单 备份与恢复 Email 设置 Git LFS 设置 HTTPS配置 设置 Fail2ban 反向代理 嵌入资源提取工具 配置说明 日志配置 邮件模板 仓库索引器 GPG 提交签名 细粒度用户角色 ✓ ✘ ✘ ✓ ✓ ✘ ✘ 提交人的身份验 证 ⁄ ✘ ? ✓ ✓ ✓ ✘ GPG 签名的提交 ✓ ✘ ✓ ✓ ✓ ✓ ✓ SSH 签名的提交 ✓ ✘ ✓ ✓ ✓ ? ? 拒绝未通过验证 的提交 ✓ ✘ ✓ ✓ ✓ ✓ ✓ 外部仓库迁移 ✓ ✘ ✓ ✓ ✓ ✓ ✓ 仓库活跃度页面 ✓ ✘ ✓ ✓ ✓ ✓ ✓ 分支管理 ✓ ✘ ✓ ✓ ✓ ✓ ✓ 建立新分支 ✓ ✘ ✓ ✓ ✓ 支持 OpenId 连接 ✓ ✘ ✓ ✓ ✓ ? ✘ 集成 OAuth 2.0（外部授权） ✓ ✘ ⁄ ✓ ✓ ? ✓ 作为 OAuth 2.0 provider ✓ ✘ ✓ ✓ ✓ ✓ ✘ 二次验证 (2FA) ✓ ✓ ✓ ✓ ✓ ✓ ✘ 集成 Mattermost/Slack ✓ ✓ ⁄ ✓ ✓ ⁄ ✓ 集成 Discord ✓ ✓ ✓ ✓ ✓ ✘ ✘ 集成 Microsoft Teams

#查看git软件版本 git version 2.39.1 ★全局设置 设置用户名和邮箱，只用于提交commit时做metadata信息，不用于身份验证 #全局设置信息保存在 ~/.gitconfig 文件里 # git config --global user.name cof #设置用户名 # cof@cof-lee.com #设置邮箱 # git config --global h�p.sslVerify false #不验证ssl证书 # git config --global --list #查看全局设置 ★本地设置 针 对 单 一 项 目 user.email cof@cof-lee.com #设置邮箱 # git config --local h�p.sslVerify false #不验证ssl证书 # git config --local --list #查看本地设置 ★系统设置 系统设置信息保存在/etc/gitconfig文件里

确定引入了哪些东西 将贡献的工作整合进来 为发布打标签 生成一个构建号 准备一次发布 制作提交简报 总结 GitHub 账户的创建和配置 SSH 访问 头像 邮件地址 两步验证 对项目做出贡献 派生项目 GitHub 流程 拉取请求的进阶用法 GitHub 风格的 Markdown 让你的 GitHub 公共仓库保持更新 维护项目 创建新的版本库 添加合作者 祖先引用 提交区间 交互式暂存 暂存与取消暂存文件 暂存补丁 贮藏与清理 贮藏工作 贮藏的创意性使用 从贮藏创建一个分支 清理工作目录 签署工作 GPG 介绍 签署标签 验证标签 签署提交 每个人必须签署 搜索 Git Grep Git 日志搜索 重写历史 修改最后一次提交 修改多个提交信息 重新排序提交 压缩提交 拆分提交 核武器级选项：filter-branch 你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先 的样子。 但额外增加的工作量却微乎其微。 本地版本控制系统 许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上 备份时间以示区别。 这么做唯一的好处就是简单，但是特别容易犯错。 有时 候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。 为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都

味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。 但额外增加 的工作量却微乎其微。 本地版本控制系统 许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。 这么做唯一 的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的 文件。 为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文 上维护本地数据库来得轻松容易。 事分两面，有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时 内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无 疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。 本地版本控制 系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。 而是把代码仓库完整地镜像下来，包 括完整的历史记录。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本 地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。 16 图表 3. 分布式版本控制. 更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分 别和不同工作小组的人相互协作。 你可以根据需要设定不