前端团队的代码，怎样才能更好的管理？

背景

寻找合适的工具

背景

最近在整理电脑文件时，发现了很久以前自己创建的前端项目及相关的文档，虽然只是一个用vue2写的H5列表页和详情页模板；但回顾过程，以前写完的代码用build打包，xshell连接堡垒机，再基于xftp将dist目录拖动到目标文件夹完成代码更新。也想起了团队协作开发时各种代码不同步和节奏不协调的问题，关于如何才能更好管理前端代码，以现在的视角回顾，我认为是有必要重新梳理和沉淀一下了。

寻找合适的工具

当时使用的这套流程，如果是一个人开发，可能是比较快速的方式，但随着业务标准化和产品化之后，就远远不适应团队的协作开发了。市面上也迅速出现了一些代码管理系统，旨在简化团队协作和代码管理流程，从而提高开发效能。

工欲善其事，必先利其器，选择一款适合当下团队的代码管理工具就十分重要。如我们公司现在使用的阿里云云效，这是一个DevOps，将项目管理、代码管理、知识库等元素集成到一起的一个产品，非常适合大型产品开发管理使用。由于我们公司一直使用阿里云的服务器，所以使用云效产品是成本最低的一种选择方式。当然，市面上也有一些类似的产品，如Teambition、PingCode、TADP、禅道、gitee等。

建立代码仓库

管理的对象是代码，那么创建一个代码仓库以便我们在团队合作时，对代码进行统一管理，也有利于公司的组织过程资产和知识产权建立。

代码组、代码库属于一对多的关系；代码组可以用来区分项目，比如标准产品或者某个项目的定制开发。代码组里有若干个代码库，有某个项目的所有代码工程。

施行版本控制

Git是目前企业中最流行的一种版本控制工具，适用于目前的团队协作开发，每个人都可以在自己的分支上独立开发，然后将自己的次要分支合并到主要分支上。开发人员可以做克隆仓库代码、同步分支代码、提交合并请求、解决冲突等操作。

对于大型项目，比较主流的就是Git Flow工作流，将主要分支分成了master、develop、release、feature等，以便适应更复杂的环境。我们团队引入的版本控制流程算是借鉴了Git Flow的思想，但有所差异，分为了开发分支、测试分支以及生产分支，分别对应开发环境、测试环境、预发布于线上环境。

自动化集成部署

像云效这类产品也提供了自动化集成和部署的服务，解放我们的双手，可以不再手动打包前端项目了。

持续集成（CI）：在构建中可以执行自动化测试、流水检查、构建打包等任务，可以发现一些低级错误，以确保部署的代码具有可靠性。

持续部署（CD）：可针对不同的环境进行配置和自动化部署。

控制权限

当前端团队人数较多时，对于权限的控制就十分重要了。试想如果每个人都有权限无条件合代码、发版，那么过程是不可控的，代码的质量也无法得到保障。

对于不同环境不同的作用，可以结合开发效率和风险管理，针对性配置权限。

开发环境（develop）：便于开发人员自测开发后的效果。
测试环境（release）：便于测试人员去测试和回归功能。
预发布环境（master）：模拟生产环境供所有人去测试最终的可交付成果。
生产环境（master）：客户使用的环境。

代码合并权限

开发分支（develop）：需要权限控制，但相对宽松。除了前端负责人、技术经理外，可以指定某迭代或者某版本开发人员负责人拥有权限，需评审代码没问题后方可合并，既能保证开发效率，也可管理一定的代码质量。
测试分支（release）：需要较严格的权限控制。可以专门指定负责人负责代码的合并工作，如前端负责人、架构师，以确保合并代码时有较严格的评审工作。
生产分支（master）：最为严格，仅前端负责人及其backup拥有，作为代码评审最后一道坎，需要严格管理。