1. 接受需求任务

2. 创建需求分支

3. 编写需求代码

4. 编写测试代码

5. Push需求分支

6. 提交Pull Request

7. 触发CI代码检测

8. 人工代码Review

9. 合并到主干分支

10. 完成需求任务

一般产品的需求是由产品来编写的，然后根据版本规划来确定哪些需求需要在当前版本完成，这些需要完成的需求就会分配给开发者，然后就创建了需求任务。有时一个需求可能由多个开发者共同完成，每个任务在看板开发模式里就是一张卡片，然后随着工作流进行移动。

第一步：模拟产品在Github仓库创建一个需求，如下图：

可通过点击Issues进入需求池界面，然后点击New Issue按钮进入上图的创建页面，填写需求信息，然后分配到项目中。

第二步：把需求分配给自己，放到待办需求中，如下图：

在版本规划阶段就需要将每个需求分配给开发者，可以点Projects进入项目页面，首先把需要这个版本开发的需求卡片放到待办需求列表中，然后把需求分配给开发者，当开发者开始开发前，需要把卡片拖到进行中。

当把需要开发的任务卡片拖到进行中后，我们就可以创建一个分支来进行开发了。为什么要创建分支呢？因为通过分支开发方式，我们不会在提交代码时影响别人的开发，每个人都是独立开发的，只有当我们的需求开发测试完，再合并到主干分支中。创建分支一般分为在线创建和离线创建，下面演示一下如何在线创建一个分支：

在线创建分支的好处是直接就可以在仓库里看到了，创建好后需要把分支Pull到本地；缺点就是创建错了也需要在线进行删除，无法本地删除。

下面演示一下如何本地创建一个分支：

本地创建分支的优点就在于如果创建有问题，随时在本地删除即可，在仓库是看不到的。而且本地会自动切换到该分支，不需要再Pull下来，推荐此方式。

在创建分支的时候有个约定，如果是团队多人开发，分支名称前缀写自己的名字，后面写需求名称，如star-lord/edit_profile。这样做的好处就是别人通过看到这个分支名称就知道是谁的分支，做什么需求的。

创建完分支之后，就可以在该分支进行代码编写了。编写的过程中，建议每完成一小阶段目标的代码，就Commit一下，最后一次性Push到仓库。那什么是小阶段目标的代码呢？比如用户编辑信息的需求，第一个小阶段可以是编写完代码结构，第二小阶段是完成初版代码，第三个小阶段可以是写好测试代码，第四个小阶段可以是最终优化版的代码，最后就可以Push到仓库了。采用分阶段Commit的好处是，可以保存一段工作时间的成果，如果继续往后做的过程始终有问题，可以通过Git reset功能还原到之前可以稳定的状态。下面演示一下如何进行Commit：

1. 先通过Rescan扫描变动的文件

2. 用Stage Changed把变动的文件添加到提交队列

3. 填写Commit Message

4. 按Commit进行提交

编写完需求代码之后，一定要编写测试代码，通过测试代码可以验证你的需求代码是否完成需求中的所有功能，特别是验证一些特殊情况下，代码是否还能执行通过。除了这个好处外，写好的测试代码，也可以保证自己或别人在日后修改这段代码的时候，避免出现BUG，只要重复执行测试用例即可，如下图：

在编写测试代码的时候，对于功能函数尽量做到分支覆盖，把各种分支情况都模拟出来，通过断言的方式来判断代码是否执行成功。此外，测试代码会交给CI工具去执行，每次完成新的需求都会进行一次全量的代码测试，避免新的需求影响旧的需求。

完成测试代码后，在本地测试没问题后，我们就可以把代码Push到仓库了，下面演示一下如何进行Push:

Push完分支后，我们的需求代码只是推到了自己分支里，如果我们想要合并到主干，需要提一个Pull Request，如下图：

提了Pull Request后，就需要在任务看板中，把我们的任务拖动到验收中。

当我们提了Pull Request后，会自动触发Github Action的检测，如下图所示：

Github Action可以自己配置一些执行动作，我们这里只是跑了一下Golang的单元测试，如下图所示：

虽然CI的自动检测没问题，但是我们还是要进行一下人工的代码Review，来查找一些CI没有发现的问题，如下图所示：

如果你的代码被发现有问题后，你可以跟提交者沟通，然后继续在需求分支修改代码，然后提交Push上来。

当通过人工Review后，我们就可以把我们的分支合并到主干分支，如下图：

合并后，上面会提示Delete Branch，点击即可。下个需求我们会再创建一个分支，每个需求任务对应一个分支。

一般合并到主干后，还会触发Github Action把代码部署到服务器上，实现持续交付。

1. 完成需求任务

当我们的代码合并到主干后，也就说明我们的任务完成了，需要在项目中拖动我们的卡片到完成列表中。

如果这个任务代表了整个需求，产品在主干分支验收完需求后，就可以把这个需求关闭了，如图所示：

通过上面的演示，我们完成了一个任务需求，这个流程主要保证我们的代码的安全性（通过测试用例、CI检测）以及代码的规范性（通过人工Review），此外在开发过程中，开发人员之间是相互独立不干扰的，推荐你在项目开发过程中采用此流程。

如果在搭建Golang开发环境过程中遇到问题或者在平时工作中有Golang问题都可我加微信进行咨询帮助: itlike000