>[info] git工作流的好处，为什么要用它 GIT工作流是团队协作积累的代码治理经验。在敏捷开发中，选择合理的、灵活的、可靠的代码管理方式，可优化产研各阶段的在制品数量限制并<span style="color:red;"><b>提高协作效率，保障生产安全。</b></span> ***** 每个团队都会有一套自己代码管理流程，随着业务发展和项目规模变化，管理流程也需要不断适应改变。就像敏捷一样，是方法论而非生搬硬套。 ***** 1. 项目管理 **模块分工：** 前端模块分工可通过一个codebase多个文件夹，采用集中式工作流在一个主分支上协作开发。对于规模复杂度较高 的项目，涉及跨工种且模块化开发，可通过git子项目关联，或者类似lerna分包分版本管理。 **代码 Review：** 促成了PR工作流，代码库的生产代码统一管控，即可做到技术层面的代码审查。借助于gitlab的issue管理、代码批 注功能，可以使版本代码可溯源，可沉淀知识库。 ***** 2. 版本控制 **集成版本树：** 版本控制需要从需求版本到部署应用版本建立统一的版本树。项目复杂度越高，不确定和不可控是需求推进的阻碍。 建立集成版本树即可辅助团队协作亦可推动各模块自检梳理应用 **生产安全控制：** 有了版本控制，不是一定杜绝了生产隐患。而是通过版本去锁定事故范围，快速定位问题 ***** **SVN 工作流：**  ***** >[info] git有哪些主流的工作流，及其分析 1. 集中式工作流 类似于集中式版本控制，以中央仓库作为项目所有修改的单点实体，在git中我们使用master分支作为主干分支，所 有修改都提交到master上，在集中式工作流中我们只使用master。  **注意事项：** 设定分支保护，防止冲突者强制覆盖 ***** 2. 功能分支工作流 功能分支工作流是为了解决开发过程中功能模块协作问题，不在master分支上做开发，每个功能模块基于一个专门 的分支。功能开发促成了Pull Request 工作流，每个PR让技术负责人review代码，检查无误后merge到master分支上。 ***** **原理：** 新增了很多功能分支，某个功能分支的功能开发完成后，可以合并到master然后发布上线，也可以先合并到test测试分支，然后再合并到master分支，再发布上线。  **使用攻略：** 拉取远程仓库，基于master创建新分支feature并同步到远程，规定该功能分支是最小需求单元的协作分支，提测过 程是将该分支Merge request到测试分支，发布线上也是将该分支合并至master。 ***** 3. Git flow工作流（重点） Git flow工作流是围绕项目发布的严格分支模型，用于管理大型项目，严格规范发布流程。 远程仓库作为开发者的交互中心，同时围绕master、release、develop、feature（feature是统称不止这一个）四种 分支协作，完成多环境、多任务的代码管理。  ***** **使用攻略：** feature功能分支是基于develop进行创建，在功能分支上进行一个周期的功能开发，多个功能并行开发就需要建立多 个feature-XXXX分支。 如果一个功能预备上线，需要先合并到develop分支上，并同时在此时develop上基础上建立一个release-XXXX分支 在此release分支上进行发布任务开发，比如bug修复，更新文档等，投产日合并release分支代码到master和 develop，并且在master上对这次merge记录版本号，并打上tag。 ***** **总结：** 此工作流适合2C产品或者对发布产品进行严格控制的项目以及大型项目处理多需求并行开发，release分支进 行预投产测试，develop进行开发测试。 ***** 4. Github工作流 pull request 基于GitHub仓库开发，开源项目严格管理PR。  >[info] Git flow工作流实操 见git文档（二）