需求 gitea release 时，上传的二进制文件大小提示受限. gitea exceeds the maximum size of (4 MB). 解决 修改 gitea 配置文件，在 gitea/conf/app.ini 里面。在 [attachment] 这一项下面增加 MAX_SIZE 和 MAX_FILES. [attachment] PATH = /data/gitea/attachments MAX_SIZE = 128 MAX_FILES = 16 注意， [repository.upload] 下面也有 FILE_MAX_SIZE 和 MAX_FILES, 但是这两个设置之后，并不能解决问题。只有 [attachment] 下面的才是有效的。 参考 Configuration Cheat Sheet 1.19.4 Configuration Cheat Sheet 1.21-dev Increase repository release upload max files limit gitea上传大小限制
需求 gitea 如何 release 解决 release 之前，首先需要打 tag. 有了 tag 之后，才能在 gitea 上面如下操作: tag 页面，找到具体的 tag，然后点击对应的 release 跳转到 release 页面，填写相应的标题和内容，把二进制文件等其他的的附件拖进去。 勾选 use the title and content of release as tag message, 这个表示在 release 页面，具体的某个 release 使用你填写的标题和内容。 如果二进制文件后期还需要调整等情况，可以勾选 mark as pre-release, 这个是预发布。 保存为草稿或者直接发布。 参考 怎样在github上发布pre-release和release?（我跟着这个操作成功了） git tag 以及发布 release git中tag与release的创建以及两者的区别
需求 git 如何 打 tag 解决 查看最新提交 git log -1 --pretty=format:"%H" 轻量 tag lightweight tag 仅仅只是一个引用，不会存储额外信息。格式 git tag {标签名} {提交ID}, 例如: git tag v0.1.0 e2356d 打上类似这样的轻量标签即可。如果是给最新的提交打 tag, 那么只需要 git tag v0.1.0 这样即可。 注释 tag annotated tag 是一个完整对象，有标签名，标签信息，标签签名等。格式 git tag -a {标签名} -m "{标签信息}" {提交ID}, 例如: git tag -a v1.0.0 -m "Release version 1.0.0" HEAD. 推送 tag git push origin {标签名} 这样可以推送指定标签。 git push origin --tags 把所有 tag 推送到服务器。 删除 tag 删除本地 git tag -d {标签名} 删除远程 git push origin :refs/tags/{标签名} 参考 Git优雅使用：git tag操作...
需求 普通项目目录中的 .git 仓库希望转为 gitea 之类所使用的裸仓库。 解决 使用 git clone --mirror 或者 git clone --bare. 两者的区别是: bare 会把仓库中已有的相应的分支整理出来。本地没有的分支和相关合并信息全部舍弃。 mirror 不管本地仓库中有没有这个分支，都把相关的分支和合并信息全部保留。 参考 如何将普通的Git仓库转换为裸仓库？ How to convert a normal Git repository to a bare one? What’s the difference between git clone –mirror and git clone –bare When creating a git repository that will be on the server, can I convert it to a bare repository? {duplicate} {Git} 裸代码仓库和镜像代码仓库全解 git clone –mirror 和 git clone –bare 有什么区别
需求 了解 gitea 的 ci/cd 需要用到的 actions 解决 gitea 推出了 Actions 来实现 CI/CD 方案。需要在 Gitea 1.19.0 及以上的版本才能支持。需要在 gitea/conf/app.ini 中添加如下配置: # 添加此配置 [actions] ENABLED = true 后面具体配置可以参考: Gitea Actions 搭建 Gitea Actions 带你体验 CI/CD 自动化工作流 体验 Gitea Actions 体验 Gitea Actions https://blog.gitea.com/2022/12/feature-preview-gitea-actions/ 参考
需求 gitea 中当某个仓库需要开发组多人使用时，就不太适合直接推送，而是应该使用 pull request 来管理合并了。使用时需要如何配置，才能满足多人请求，单人审核的权限需求，以及选用哪种方法进行合并? 解决 分支 master 只能从 release 合并过来。仓库设置 -> branch 开启分支推送保护，并且合并白名单设置只能指定的测试人员才能把 release 中的某个提交合并到 master 上去。 develop 不能直接推送，必须从其他的个人分支合并过来。也是开启分支推送保护，并且合并白名单只能由管理员才能合并过来。 权限 leader 管理员的权限需求为: 不能删除仓库 管理仓库的方方面面 管理从其他分支到 develop 分支的合并 解决方法即为: 在组织中创建 team, 命名为 admin , 设置为 spec repo 和 admin access 即可。 把允许管理的仓库添加给 admin team. 只要不是 own team, 就不能删除仓库。 把 admin team 加入到 develop 的合并白名单 把具体的 leader 加入到这个 admin team 中去。 develop 开发人员的权限需求为: 可以推送除了 master, develop, release 以外的分支 只访问允许的仓库 解决方法为...