事先声明，纯纯做记录用，如果有哪里说的不对请留一下言哦！
前言
由于我自己之前完全没有接触过相对 系统性 的github协作开发，而最近在实习的过程中技术主管和我科普了一下比较符合实际的规范协作流程，于是我想着写一篇文章来总结一下。
首先我们需要知道在一个项目中，你如果是作为团队的一员，那么所有的分支、issue以及PR都应该是以 你所完成的单个功能 为单位。一个个 功能 的不断被实现，最终拼凑出一个完整的项目。而且以功能作为协作开发的单位的话，也使得整个项目变得比较容易去追溯维护。如果某个功能出现了问题，直接去找实现这个功能的成员就可以了。
Github提供的项目工具
首先我们可以看一下github中一个项目的主要界面tabs：
- Code: 整个项目的代码资源。
- Issue: 这个项目当前需要完成、处理的一些功能、bug修复等。在这里就是对这个项目进行计划的声明的，说明接下来要完成什么事情。 这个是最最最基本的团队协作的工具。
- Pull requests: 就是PR。一般团队成员从main分支拉取了最新的内容之后，便checkout到他们自己的分支上进行开发。当功能初步测试完成，开发完毕后，便可以远程提交到仓库的这个分支上，然后提交一个PR， 表示我目前的活已经干完了，要和main合并。
- Actions: 就是Github workflow，github工作流。一般就用于 CI/CD 的一些操作，或者提PR后和main进行merge之前的一些验证操作。
- Projects: 是一个项目管理工具，可以创建多个项目看板来跟踪不同方面的工作。每个项目看板都可以包含多个列，这些列代表任务的不同阶段，如"待办事项"、"进行中"、"已完成"等。 不过目前在Github上面用这个的好像比较少，更多的都是在自己团队内部的一些工单软件中统筹的，比如飞书的工单推进。
- Security: 主要就是用来维护整个项目的安全性的，平时用的也比较少。旨在帮助开发者发现并修复安全漏洞。
- Insights: 和它的名字一样，就是用来统计汇总关于这个项目的全部数据的。它提供了一系列的统计数据和视图，帮助开发者和项目维护者理解项目的健康状况、贡献者活动和其他重要指标。
一般流程梳理
任务到功能
我们如果自己作为团队成员，我们的技术负责人会给我们派发一些开发的任务。 我们首先第一件事就是把这个一个任务拆成功能。 一般而言，如果是相对比较合格的技术负责人，给自己的员工派任务都是以功能为单位进行的。我们如果作为个人开发者，做自己个人的项目， 保持这样的习惯也是非常好的。
比如目前突然有个新项目的UI画好了，然后技术负责人找你说你一个人 把这整个项目的UI全部画了 ，这就是一个新任务。有些项目的UI是非常复杂难画的，可能一天画不完，这个时候就是要将其拆成一个个功能的实现。比如你可以按照一个个页面进行UI绘制，把每个页面的UI、基础互动功能、假数据全部完成作为这个页面的绘制功能实现。
功能到Issue
功能确认完毕，开始进行Issue的编写。Issue分 Open 和 Close 。Open的Issue就是目前正在推进中的任务，Close的表示已经完成了。
Issue应该是以 任务 为单位，也就是说你每一次和负责人沟通完毕或者你自己打算给自己的个人项目开工的时候，你就应该new一个Issue。我们可以看一下Issue界面：
可以看到每个Issue主要由Issue名称、Issue Tags、Issue的描述内容、Issue对应的PR、Issue的负责人组成。
-
Issue名称: 取名方式和一般的团队协作commit方式差不多，也是以feat、fix、chore等开头，后面的括号是指定这个功能对应的项目名称（Monorepo等多项目单仓库管理模式适用，如果是涉及到项目全局的一些功能实现就用all）。后面跟 **: ** ，然后写这个Issue对应的任务名。
-
Issue Tags: 这就是给每个Issue打标签，标明这个Issue是啥类型的。
标签是团队内部一起指定的，可以根据实现任务的类型、所处理的不同项目等进行分类。github内置的标签就是以任务类型来分的。一个Issue得携带标签，标明这个任务的性质是什么，对应的是哪个项目，方便后续的维护与项目进度统筹。
-
Issue的描述内容: 这里一般是以 markdown中任务列表 的格式进行书写，也就是
- [ ] <功能实现需求>的格式。每一条任务就代表着这个任务所拆分出来的每一个功能，你接下来的开发就是对着这几个功能进行开发，本地完成了之后就给这个功能打勾。 -
Issue对应的PR: 每一个功能的完成都应该对应着一个PR，在后面可以加上
#来触发对于PR的选择。 我们在完成了一个功能之后，确认无误就可以提交到远程分支然后提个PR了。提了之后，就可以到你自己刚刚的Issue，勾掉你的任务，然后在任务后面加一个#，选择PR。 -
Issue的负责人: 就是上面的Assignees。一般你自己new出来你自己新的issue，负责人一般也就是你；如果你的技术负责人分派给你任务并且提前新建好了Issue，他可能就会指定你为Assignees。
Issue到PR
到这一步意味着你得正式开始干活了。
-
你需要从main分支切出一个新分支，这个分支的命名就代表着你当前决定要处理的 功能 （不是任务）。
-
然后你开始干活。这是一个比较漫长且辛苦的过程。
-
干完活并且本地测试可以跑通之后就可以进行commit了。commit的话必须要遵循团队的commit规范，一般是通过
commitlint+husky等的管理工具进行commit信息的校验，只有符合格式的才能够通过校验成功commit。 -
成功commit之后就可以提交到远程的分支，最后就是提PR了。上面其实已经讲的差不多了，不过有一些细节补充一下。
和Issue的#相对应，在PR中你可以在PR描述中描述清楚你干了什么，最后加一个 close #<Issue编号> 来自动触发Merge后删除Issue的功能。 不过这个只在最后的PR完成了一整个Issue的所有任务后进行，其他时间就无需使用。
顺带一提，这边可以看到一个PR有两个Check，这个是通过Github的workflow进行配置的。具体的配置方式也是按照团队的不同来进行。
PR到main
当技术负责人或者你自己将你的PR合并到main上之后，直接把这个远程分支删掉，然后你把本地的分支删掉，最后切换到main再把最新的远程main分支内容pull到本地，确保下一次任务开始之前你本地的代码是最新的，避免了冲突的风险。
最后
这样子就完成了一个比较基本的开发流程，接下来的每一步开发就是按照这样的流程循环进行。
当然，如果你的项目只有你一个人开发，那么你也可以按照这样的流程来走，不过可以进行一定程度的简化。 我个人觉得自己开发的时候也遵循这样的流程对未来的开发积累是非常有利的，虽然在一定程度上会降低开发的效率。