目录
前言
正文
关于分支保护
特别说明
如何在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