次合并。 你抓取 了这些在远程分支上的修改，并将其合并到你本地的开发分支，然后你的提交 历史就会变成这样： 图表 45. 抓取别人的提交，合并到自己的开发分支 接下来，这个人又决定把合并操作回滚，改用变基；继而又用 git push -- force 命令覆盖了服务器上的提交历史。 之后你从服务器抓取更新，会发现多 出来一些新的提交。 图表 46. 有人推送了经过变基的提交，并丢弃了你的本地开发所基于的一些提交 jessica@githost:simplegit.git 72bbc59..8059c15 master -> master 每一个开发者都提交了几次并成功地合并了其他人的工作。 图表 64. 推送所有的改动回服务器后 Jessica 的历史 这是一个最简单的工作流程。 你通常会在一个主题分支上工作一会儿，当它 准备好整合时就合并到你的 master 分支。 当想要共享工作时，如果有改动的 话就抓取它然后合并到你自己的  你可以用 rebase -i 将工作压缩成一个单独的提交，或者重排提交中的工作使补丁更容易被 维护者审核—— 查看 重写历史 了解关于交互式变基的更多信息。 当你的分支工作完成后准备将其贡献回维护者，去原始项目中然后点击“Fork” 按钮，创建一份自己的可写的项目派生仓库。 然后需要在本地仓库中将该仓 库添加为一个新的远程仓库，在本例中称作 myfork： $ git remote add

合并。 你抓取了这些在远程分支上的修改，并将 其合并到你本地的开发分支，然后你的提交历史就会变成这样： 99 图表 45. 抓取别人的提交，合并到自己的开发分支 接下来，这个人又决定把合并操作回滚，改用变基；继而又用 git push --force 命令覆盖了服务器上的提交 历史。 之后你从服务器抓取更新，会发现多出来一些新的提交。 100 图表 46. 有人推送了经过变基的提交，并丢弃了你的本地开发所基于的一些提交 克隆出一个自己的公开仓库，然后将自己的修改推送上去。 接着你可以请求官方仓库的维护者拉取更新合并到 主项目。 维护者可以将你的仓库作为远程仓库添加进来，在本地测试你的变更，将其合并入他们的分支并推送 回官方仓库。 这一流程的工作方式如下所示（见 集成管理者工作流。）： 1. 项目维护者推送到主仓库。 2. 贡献者克隆此仓库，做出修改。 3. 贡献者将数据推送到自己的公开仓库。 4. 贡献者给维护者发送邮件，请求拉取自己的更新。 jessica@githost:simplegit.git 72bbc59..8059c15 master -> master 每一个开发者都提交了几次并成功地合并了其他人的工作。 134 图表 64. 推送所有的改动回服务器后 Jessica 的历史 这是一个最简单的工作流程。 你通常会在一个主题分支上工作一会儿，当它准备好整合时就合并到你的 master 分支。 当想要共享工作时，如果有改动的话就抓取它然后合并到你自己的

全性。 代码评审：代码评审同时支持 Pull Request workflow 和 AGit workflow。评审⼈可以在线浏览代 码，并提交评审意见或问题。 提交者可以接收到评审意见，并在线回 复或修改代码。代码评审可以帮助用户 和企业提⾼代码质量。 CI/CD: Gitea Actions⽀持 CI/CD 功能，该功能兼容 GitHub Actions，⽤⼾可以采用熟悉的YAML格 过签名的 URL 提供 Minio/S3，本地不执行任何操作。 PATH ：./data/lfs：存储 LFS 文件的位置，仅在 STORAGE_TYPE 为 local 时可用。如果未设置，则回 退到 [server] 部分中已弃用的 LFS_CONTENT_PATH 值。 MINIO_ENDPOINT ：localhost:9000：连接的 Minio 终端点，仅在 STORAGE_TYPE 包。在同一级别的子包中，可以根据该级别 的规则进行依赖。 注意事项 为什么我们需要在 models 之外使用数据库事务？以及如何使用？ 某些操作在数据库记录插入/更新/删除失败时应 该允许回滚。 因此，服务必须能够创建数据库事务。以下是一些示例： 1. // services/repository/repository.go 2. func CreateXXXX() error {