很多团队每天花很多时间切换不同的工具中来做代码版本控制和项目管理！我们是否可以减少在这个过程中浪费的时间？能不能「直接」在单个系统内完成以上操作？

废话不多说，一起看看开源中国如何使用码云完成开发？

------ 华丽分割线 -------

开源中国内部团队包括前端、后端、设计、产品、运营，用码云（Gitee）来托管所有代码和管理项目，如下图所示（企业团队只会显示该成员参与的团队，未参与团队没有权限看到）。

1、需求阶段（需求收集、分析和评审）

产品团队通过分析往期功能的数据来确定是否要做调整和改进，以及结合用户的反馈来确定是否要添加某一项新功能。产品团队内部评审和优化之后，产品经理会和各个业务的技术负责人再一起去做需求的评审，确保需求的合理性和重要程度。

创建一个「需求管理」的任务类型，将这一流程分解为需求收集-需求分析-需求评审三个阶段（自定义任务状态），分别建立对应的任务列表。每收到一条用户需求，就在「需求收集」的列表上新建一条任务，具体的使用场景备注在任务详情中。

接下来，产品团队预先一两周给出需要开发的任务，这些任务会在技术组内会花半天时间讨论，将产品 Task 再次拆分为子任务（独立最小需求），同时在子任务中填写预估完成的时间和设置任务的优先级。再将各个子任务分配到人（责任制）。如下图所示，码云任务功能模块可以非常清晰的看到整个需求被拆成了多少个子任务，有助于整体项目的把控。

子任务：

另外，成员需添加通知设置（个人设置页面 - 通知设置），之后当需求发生改变的时候，都会自动发送信息给这个需求任务中的同事，节省了需求变更后的沟通成本。

除此之外，开源中国内部引入每日站会。大家从无话可说，听不懂别人说什么，到现在必须限制每人的发言时间，说明大家对于项目整体有了比较清晰的全局观！不仅如此，开发团队每周五下午都会抽出一到两个小时分享各自的心得，实行一段时间后，能明显感受到团队的信心和凝聚力在增长。且每次分享结束后，业务负责人都会将其中精华整理成知识库放在 wikis 中，以供成员随时查阅。

2、设计阶段（设计需求、原型设计、视觉设计）

当需求确定之后，产品就可以进入到设计阶段。创建一个「产品设计」的任务类型，将这一流程分解为设计需求-原型设计-视觉设计三个阶段（自定义任务状态），分别建立对应的任务列表。

在【产品设计】中新建设计需求，并在任务详情中描述需求细节和注意事项。

当设计完成时，设计师将本地的设计稿上传到任务的附件中，再通知研发部门的负责人，并交付设计。研发部门的负责人发表意见时，可以在评论区通过@的方式知会到相关人员，被@的人可以通过站内信接收到通知。

3、开发阶段（开发、提交 PR、代码审核、测试）

产品设计完成后，进入开发阶段。开源中国内部研发人员一般的开发流程如下：

• 在码云上进行 Fork 项目代码；
• 将上述的仓库 clone 到本地；
• 在本地环境中创建开发分支；
• 对开发分支进行代码修改并提交；
• 将开发分支代码 push 到码云上相应仓库中；
• 在码云上向源仓库（项目代码）发送 Pull Request；
• 项目负责人对提交的 Pull Request 做代码审核；
• 如果通过，则合并该 Pull Request；不通过，则说明原因重新修改，然后再提交。

看到这里，你可以会想，工程师提交的 Pull Request 如何跟前面我们提到的码云任务管理模块相关联呢？开发团队如何在 Pull Request 中做代码审核呢？ Pull Request 相比较传统模式有什么优势么？

3.1、PR 关联任务

举个简单的例子，当你提交的代码是解决了一个 bug，或者一个 feature 的时候，你想要任务与这次提交的信息产生关联该怎么办？码云支持代码提交和任务建立关联，你可以在提交代码时候通过在 commit 的信息里面加上“#xxx”（任务编号）将代码与任务关联起来，比如：

git commit -m “XXX #IGFM5”

任务 ID 为 IGFM5 的任务将会产生一个关联信息，这样更方便任务追踪管理以及 bug 追踪管理，关联后效果如图所示：

或者也可以在 Pull Request 的评论中关联任务。

如果在提交说明中的问题编号前出现特定关键字，还可以关闭任务，如：fix #xxx。

3.2、PR 代码评审

码云上的 Pull Request 作为一个非常有用的代码审查工具，通过 Pull Request @相关团队成员 让对方审阅自己的代码，指定成员跳转到指定分支后可以对代码进行评论，提出改善建议，帮助改善逻辑及缺陷。

码云平台限制 Pull Request 源项目与目标项目需存在 fork 与被 fork 关系，故如果你要提交 Pull Request，必须先 fork 一个项目，然后才能对该项目提交 Pull Request，同时，以该项目为父项目的所有项目，您也均可以提交 Pull Request。但提交 Pull Request 时，您的项目与目标项目必须存在差异。如果不存在差异，或者目标分支比你提 Pull Request 的分支还要新，则不能提交 Pull Request 。

点击“新建 Pull Request”填入 Pull Request 的说明，点击提交 Pull Request，就可以提交一个 Pull Request 了。

3.3、PR 代码比对

提交 PR 后，我们可以通过双栏对比查看修改文件和源文件之间的差异。

3.4、PR 按行评论

我们可以对指定代码进行提问及评论，回答并展开讨论。

通过讨论和评论的方式对代码进行不断的重构和改善，直至指派的审查人员和测试人员对代码完成审查并通过后才能进行最终合并。

4、缺陷管理

创建一个「缺陷管理」的任务类型，将这一流程分解为新提交-处理中-测试中-已解决四个阶段（自定义任务状态），分别建立对应的任务列表。

利用任务中的「优先级」标注 Bug 处理的顺序与严重程度。

同时可以利用「标签」 对存在的 Bug 进行清晰地归类与存档管理。

• 功能错误：功能上的错误性 bug。

• 代码错误：通常在自测时出现（对白盒测试、自测的比较适合）。

• 内容相关：业务逻辑方面以及业务描述等相关问题。

• 表单相关：表单逻辑、样式、内容问题。

• 用户界面：UI 表现，包括对话框样式和文字描述问题。

• 设计文档：数据库设计文档、概要/详细设计文档。

• 配置相关：如 web 服务器或者数据库服务器配置等问题。

• 安装部署：项目部署时出现的错误，可能不是程序本身的问题而是工具本身和人为因素引起。

产品上线后，收集到的用户反馈信息又会统计到 [需求管理]中，作为下一轮迭代的需求来源。

详细的产品体验请前往 https://demo.gitee.com/enterprises ，我们提供了一个 Demo 账号可以轻松体验。你还可以直接开通免费企业版，我们的免费版不限项目数，可添加 5 个开发人员哦。

当然了，即便是收费，我们也是业内的良心价。详情请看 https://gitee.com/enterprises