目录
前言
正文
关于分支保护
特别说明
如何在Windows环境下配置GitHub Desktop GPG签名？
推荐分支保护选择
关于good first issue
如何设置good first issue？
关于Project
尾声
- 🔭 Hi,I’m Pleasure1234
- 🌱 I’m currently learning Vue.js,SpringBoot,Computer Security and so on.
- 👯 I’m studying in University of Nottingham Ningbo China
- 📫 You can reach me by url below:
- My Blog Website: https://blog.yiming1234.cn
- My CSDN Blog: https://yiming1234.blog.csdn.net
- My Email:Pleasure@yiming1234.cn
- My Github:Pleasurecruise (自由的世界人) · GitHub
- It's my pleasure to see you follow me!
原文地址：如何运营Github Org - Pleasure的博客
下面是正文内容：
前言
分享近期的收获
对于这个号，尽量做到月更吧
推广一下最近在写的开源项目，求star
GitHub - CompPsyUnion/NottinghamWall: 宁诺校园墙/宁波诺丁汉大学/计算机爱好者协会
正文
建立一个Github Org并没有想象的那么困难
只需要将新注册一个Github账号然后前往Sign in to GitHub · GitHubTransform account
建立Github Org有多种目的，比如：
1.公司，社区，部门，组织，社团等具有官方性质的，用于和自由开发者进行交流
2.用于统一储存管理具有某一相同目的的仓库
这篇文章仅谈谈以下几点
关于分支保护
用于在协同工作中保护源代码的安全
以下是每个分支保护规则的简要解释：
- Restrict creations：限制分支的创建权限。仅允许具有绕过权限的用户创建符合规则的引用（refs），防止未授权的分支创建。
- Restrict updates：限制分支的更新权限。只有具有绕过权限的用户才能更新符合规则的引用，防止未经批准的更改。
- Restrict deletions：限制分支的删除权限。仅允许具有绕过权限的用户删除符合规则的引用，以防止分支意外或未经授权的删除。
- Require linear history：要求线性历史记录。阻止将带有合并提交的更改推送到符合规则的引用，确保分支历史保持线性（没有合并提交）。
- Require merge queue：要求合并队列。所有合并操作都必须通过合并队列进行，以确保变更按序进行。
- Require deployments to succeed：要求成功的部署。在推送符合规则的引用前，必须先成功部署到指定的环境，确保生产环境的稳定性。
- Require signed commits：要求签名的提交。所有推送到符合规则的引用的提交必须具备经过验证的签名，确保提交来源可信。
- Require a pull request before merging：合并前需要提交拉取请求。所有更改必须通过拉取请求合并，确保分支上的直接推送受到控制。
- Required approvals：要求批准数。拉取请求在合并前必须获得指定数量的批准，确保变更经过充分的审查。
- Dismiss stale pull request approvals when new commits are pushed：在推送新提交时撤销已过时的批准。新提交会撤销之前的批准，确保最新更改得到重新审查。
- Require review from Code Owners：需要代码所有者的审查。拉取请求中的文件变更若涉及代码所有者指定的文件，则需要代码所有者的批准。
- Require approval of the most recent reviewable push：要求最新的推送获得批准。最新的可审查推送必须由他人批准，防止提交者自行批准更改。
- Require conversation resolution before merging：要求对话解决。所有代码对话需在拉取请求合并前解决，确保沟通到位。
- Request pull request review from CopilotPreview：自动请求Copilot的审查。在新拉取请求创建时自动请求Copilot审查（若作者具备Copilot代码审查访问权限）。
- Require status checks to pass：要求状态检查通过。配置后，推送前需通过指定状态检查，确保代码符合质量标准。
- Block force pushes：禁止强制推送。防止具有推送权限的用户强制推送更改，以维护分支历史的完整性。
- Require code scanning results：要求代码扫描结果。指定工具必须提供代码扫描结果，确保推送的代码没有安全或质量问题。
对于个别规则我想进行
特别说明
Restrict updates是只允许拥有Bypass权限的用户才允许对Pull Request进行Merge，在实际操作中显示如下
只有点击Merge without waiting for requirements to be met (bypass branch protections)才能进行合并
建议不要勾选该项
Require signed commits是为了防止在本地被伪造的git被提交，需要进行签名，即这里绿色的verified！
如何在Windows环境下配置GitHub Desktop GPG签名？
首先安装GPG，下载地址：https://www.gnupg.org/download/index.html
检查环境变量是否生效，终端中输入
gpg --version
输出如下则环境变量生效
生成密钥 设置密钥的姓名，邮箱，描述，建议设置为GitHub用户名，GitHub绑定的邮箱
gpg --full-generate-key
查看密钥
gpg --list-secret-keys --keyid-format=long
gpg --armor --export 你的密钥ID然后在你的Github账户中添加刚生成的密钥
Sign in to GitHub · GitHub
在Github Desktop的文件夹中进行配置，路径大致如下
C:\Users\31968\AppData\Local\GitHubDesktop\app-3.4.9\resources\app\git\cmd
git config --global user.signingkey Your_Secret_Key
git config --global commit.gpgsign true
git config --global gpg.program "Path\To\Your\GnuPG\bin\gpg.exe"这样每次在push的时候都会对提交进行验证了
推荐分支保护选择
这里是我推荐的对于组织中开源仓库的分支保护的选择
{"id": 1578177,"name": "Protect Main","target": "branch","source_type": "Repository","source": "CompPsyUnion/NottinghamWall","enforcement": "active","conditions": {"ref_name": {"exclude": [],"include": ["~DEFAULT_BRANCH"]}},"rules": [{"type": "deletion"},{"type": "non_fast_forward"},{"type": "creation"},{"type": "pull_request","parameters": {"required_approving_review_count": 1,"dismiss_stale_reviews_on_push": true,"require_code_owner_review": false,"require_last_push_approval": true,"required_review_thread_resolution": true,"automatic_copilot_code_review_enabled": false}},{"type": "required_signatures"}],"bypass_actors": [{"actor_id": 5,"actor_type": "RepositoryRole","bypass_mode": "always"},{"actor_id": 1,"actor_type": "OrganizationAdmin","bypass_mode": "always"}]
}关于good first issue
在开源项目中，“good first issue” 是一种标签，用来标记适合新手或首次参与该项目的贡献者解决的任务。这些任务通常具有以下特点：
- 简单明了：问题通常是相对简单的，不需要深入了解项目的复杂细节。
- 难度适中：任务的难度适合初学者解决，不涉及特别复杂的逻辑或大型代码改动。
- 明确的指引：问题描述清晰，包含解决方案的方向、相关文件路径，或必要的背景信息，帮助新人快速上手。
- 低风险：通常是对项目核心功能影响较小的任务，比如小的bug修复、文档更新、代码清理等。
通过“good first issue”，项目维护者希望吸引更多新手加入贡献，熟悉项目结构和开发流程，同时为新手提供一个学习和成长的机会。
如何设置good first issue？
常见的good first issue格式如上
会在这个issue中罗列已完成和待完成的任务，并关联issue和pull request
已 number of number tasks 的形式在头部显示，已达到比在仓库README中列TODO更好的效果
同时还可以关联 Project ，Tags ，并通过issue的Assign进行task/issue的分发
关于Project
在开源合作中非常常见，比如公司 社区等等
GitHub Project 是一种项目管理工具，帮助团队在 GitHub 上进行任务和项目的规划、组织和跟踪。它结合了看板、任务列表等功能，使开发和管理团队可以更高效地协作。GitHub Project 的主要作用如下：
- 任务跟踪：项目中的问题（Issues）和拉取请求（Pull Requests）可以直接添加到项目中，方便团队跟踪任务进展。
- 优先级和进度管理：可以通过分配优先级、截止日期、里程碑等信息，帮助团队合理安排任务，确保项目按计划进行。
- 任务分配和角色分工：支持分配任务给团队成员，清晰地展示各自的职责和进展，增强协作效果。
- 自定义工作流程：支持创建自定义列（如“待办”、“进行中”、“已完成”），并支持自动化规则来改变任务状态，提升工作效率。
- 进度可视化：使用看板视图和列表视图，项目进度一目了然，便于管理者监控整个项目的实时状态。
- 整合与自动化：可以通过 GitHub Actions 或 Webhooks 自动更新任务状态。例如，某个拉取请求被合并后，任务可以自动标记为完成。
- 提升透明度：所有项目成员都可以实时看到项目状态和进度，保持信息透明，减少沟通成本。
GitHub Project 是 GitHub 项目管理的核心工具，特别适用于开源项目、团队开发项目等，使得代码开发和项目管理无缝衔接，提高整体协作效率。
尾声
如果可以的话，麻烦给我们的组织点个关注，谢谢
Computer Psycho Union · GitHub