目录

前言

正文

关于分支保护

特别说明

如何在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.用于统一储存管理具有某一相同目的的仓库

这篇文章仅谈谈以下几点

关于分支保护

用于在协同工作中保护源代码的安全

以下是每个分支保护规则的简要解释：

1. Restrict creations：限制分支的创建权限。仅允许具有绕过权限的用户创建符合规则的引用（refs），防止未授权的分支创建。
2. Restrict updates：限制分支的更新权限。只有具有绕过权限的用户才能更新符合规则的引用，防止未经批准的更改。
3. Restrict deletions：限制分支的删除权限。仅允许具有绕过权限的用户删除符合规则的引用，以防止分支意外或未经授权的删除。
4. Require linear history：要求线性历史记录。阻止将带有合并提交的更改推送到符合规则的引用，确保分支历史保持线性（没有合并提交）。
5. Require merge queue：要求合并队列。所有合并操作都必须通过合并队列进行，以确保变更按序进行。
6. Require deployments to succeed：要求成功的部署。在推送符合规则的引用前，必须先成功部署到指定的环境，确保生产环境的稳定性。
7. Require signed commits：要求签名的提交。所有推送到符合规则的引用的提交必须具备经过验证的签名，确保提交来源可信。
8. Require a pull request before merging：合并前需要提交拉取请求。所有更改必须通过拉取请求合并，确保分支上的直接推送受到控制。
9. Required approvals：要求批准数。拉取请求在合并前必须获得指定数量的批准，确保变更经过充分的审查。
10. Dismiss stale pull request approvals when new commits are pushed：在推送新提交时撤销已过时的批准。新提交会撤销之前的批准，确保最新更改得到重新审查。
11. Require review from Code Owners：需要代码所有者的审查。拉取请求中的文件变更若涉及代码所有者指定的文件，则需要代码所有者的批准。
12. Require approval of the most recent reviewable push：要求最新的推送获得批准。最新的可审查推送必须由他人批准，防止提交者自行批准更改。
13. Require conversation resolution before merging：要求对话解决。所有代码对话需在拉取请求合并前解决，确保沟通到位。
14. Request pull request review from CopilotPreview：自动请求Copilot的审查。在新拉取请求创建时自动请求Copilot审查（若作者具备Copilot代码审查访问权限）。
15. Require status checks to pass：要求状态检查通过。配置后，推送前需通过指定状态检查，确保代码符合质量标准。
16. Block force pushes：禁止强制推送。防止具有推送权限的用户强制推送更改，以维护分支历史的完整性。
17. 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” 是一种标签，用来标记适合新手或首次参与该项目的贡献者解决的任务。这些任务通常具有以下特点：

1. 简单明了：问题通常是相对简单的，不需要深入了解项目的复杂细节。
2. 难度适中：任务的难度适合初学者解决，不涉及特别复杂的逻辑或大型代码改动。
3. 明确的指引：问题描述清晰，包含解决方案的方向、相关文件路径，或必要的背景信息，帮助新人快速上手。
4. 低风险：通常是对项目核心功能影响较小的任务，比如小的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 的主要作用如下：

1. 任务跟踪：项目中的问题（Issues）和拉取请求（Pull Requests）可以直接添加到项目中，方便团队跟踪任务进展。
2. 优先级和进度管理：可以通过分配优先级、截止日期、里程碑等信息，帮助团队合理安排任务，确保项目按计划进行。
3. 任务分配和角色分工：支持分配任务给团队成员，清晰地展示各自的职责和进展，增强协作效果。
4. 自定义工作流程：支持创建自定义列（如“待办”、“进行中”、“已完成”），并支持自动化规则来改变任务状态，提升工作效率。
5. 进度可视化：使用看板视图和列表视图，项目进度一目了然，便于管理者监控整个项目的实时状态。
6. 整合与自动化：可以通过 GitHub Actions 或 Webhooks 自动更新任务状态。例如，某个拉取请求被合并后，任务可以自动标记为完成。
7. 提升透明度：所有项目成员都可以实时看到项目状态和进度，保持信息透明，减少沟通成本。

GitHub Project 是 GitHub 项目管理的核心工具，特别适用于开源项目、团队开发项目等，使得代码开发和项目管理无缝衔接，提高整体协作效率。

尾声

如果可以的话，麻烦给我们的组织点个关注，谢谢

Computer Psycho Union · GitHub