很多团队每天都会花费大量的时间在不同的工具之间切换来进行代码版本控制和项目管理！ 我们能减少这个过程中浪费的时间吗？ 上述可以在单个系统内“直接”完成吗？ 废话不多说，我们来看看开源中国是如何利用码云完成开发的？

如何设置码云工具/原材料

注册码云账号

如何设置码云操作方法

中国内部团队包括前端、后端、设计、产品、运营。 Gitee用于托管所有代码并管理项目，如下图（企业团队只会显示成员参与的Teams，不参与团队的Teams无权限查看）

如何搭建码云1.需求阶段（需求收集、分析和审核）

产品团队通过分析以往功能的数据来决定是否进行调整和改进，并根据用户反馈决定是否添加新功能。 产品团队内部审核优化后，产品经理会同各业务技术负责人一起审核需求，确保需求的合理性和重要性。 创建“需求管理”任务类型，将此流程分解为需求收集-需求分析-需求审核（自定义任务状态）三个阶段，并创建相应的任务列表。 每次收到用户需求，都会在“需求集合”列表中创建一个新的任务，并在任务详情中注明具体的使用场景。

接下来，产品团队提前一两周给出需要开发的任务。 这些任务会在技术组讨论半天，将产品任务分成子任务（独立的最低要求），同时填写子任务。 估计完成时间并设置任务优先级。 然后将每个子任务分配给一个人（责任制）。 如下图所示，码云任务功能模块可以清晰地看到整个需求被拆分成了多少个子任务，有助于对项目整体的把控。

另外，成员需要添加通知设置（个人设置页面-通知设置），然后当需求发生变化时，会自动向需求任务中的同事发送信息，节省需求变化后的沟通成本。

此外，开源中国还推出了每日站会。 大家都无话可说，也听不懂别人说的话，但现在却要限制大家的发言时间，这说明大家对项目整体有了更清晰的认识！ 不仅如此，开发团队每周五下午都会花一到两个小时来分享他们的经验。 经过一段时间的实施，团队的信心和凝聚力明显增强。 并且每次分享结束后，业务负责人都会将精华整理成知识库，放到wiki中，供会员随时查阅。

如何搭建码云2.设计阶段（设计需求、原型设计、视觉设计）

当需求确定后，产品就可以进入设计阶段。 创建“产品设计”任务类型，将此流程分解为设计需求-原型设计-视觉设计（自定义任务状态）三个阶段，并创建相应的任务列表。

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

设计完成后，设计师将本地设计稿上传至任务附件，然后通知研发部门负责人，并交付设计。 研发部门负责人发表意见时，可以在评论区通过@通知相关人员，被@的人可以通过站内消息收到通知。

如何搭建码云3.开发阶段（开发、提交PR、代码评审、）

产品设计完成后，进入开发阶段。 开源中国内部研发人员的一般开发流程如下： 1）在码云上fork项目代码； 2）将上述仓库克隆到本地； 3）在本地环境创建开发分支； 4）fork开发分支修改并提交代码； 5）、将开发分支的代码推送到码云上对应的仓库； 6）、向码云源码仓库（项目代码）发送Pull； 7）、项目负责人对提交的Pull Do代码进行审核； 8）、如果通过，则合并Pull； 如果失败，说明原因并重新修改后提交。 看到这里，你可能会想，工程师提交的pull和我们前面提到的码云任务管理模块有什么关系呢？ 开发团队如何在 Pull 中进行代码审查？ Pull 相对于传统模式有什么优势吗？

3.1. PR相关任务举个简单的例子，当你提交的代码解决了一个bug，或者一个，如果你想让任务和这次提交的信息关联起来，你该怎么办？ 码云支持代码提交与任务关联。 您可以将代码与任务关联起来，只需在提交代码时在信息中添加“#百思特网xxx”（任务编号）即可，例如： git -m "XXX #IGFM5" 任务 ID 将会为 IFM5 的任务生成相关信息，更方便任务跟踪管理和Bug跟踪管理。 链接后的效果如图所示。 或者您可以在 Pull 的评论中链接任务。 如果提交描述中问题编号之前出现特定关键字，也可以关闭任务，例如：fix #xxx。

3.2. PR 代码审查 Pull on Code Cloud 是一款非常好用的代码审查工具。 通过Pull@相关团队成员，让对方审查自己的代码。 指定成员跳转到指定分支后，可以对代码进行评论，提出改进建议。 帮助改进逻辑和错误。 码云平台限制Pull源项目和目标项目有fork和fork关系，所以如果要提交Pull，必须先fork一个项目，然后才能对该项目提交Pull。 同时，以该项目为父项目的所有项目，也可以提交Pull。 但是，提交Pull时，你的项目和目标项目之间肯定存在差异。 如果没有差异，或者目标分支比您从中拉取的分支新，则您无法提交拉取。 点击“New Pull”填写Pull的描述，点击 Pull提交Pull。

3.3. PR代码对比提交PR后，我们可以通过双列对比查看修改后的文件与源文件的差异。

3.4、按行PR评论我们可以对指定的代码进行询问和评论，回答和讨论。 代码通过讨论和评论不断重构和改进，只有指定的审核人员和人员完成代码的审核和批准后才能进行最终的合并。

如何搭建码云4.缺陷管理

创建“缺陷管理”任务类型，将此流程分解为新建百思特网提交-处理中-已解决（自定义任务状态）四个阶段，并创建相应的任务列表。

使用任务中的“优先级”来标记Bug处理的顺序和严重性。

同时，可以利用“标签”对现有的Bug进行清晰的分类和归档。 功能错误：功能错误错误。 代码错误：通常出现在自检时（比较适合白盒和自检）。 内容相关：业务逻辑方面和业务描述等相关问题。 形式相关：形式逻辑、风格、内容问题。 用户界面：UI表现，包括对话框样式和文字描述问题。 设计文档：数据库设计文档百思特网、概要/详细设计文档。 配置相关：Web 服务器或数据库服务器配置等问题。 安装部署：项目部署过程中出现的错误可能不是程序本身造成的，而是工具本身和人为因素造成的。 产品上线后，收集到的用户反馈信息将计入【需求管理】，作为下一次迭代的需求来源。

如何设置码云？