多个前端项目放在一个git好还是_前端工作流

没有规矩不成方圆，如果一个项目只有你一个人在维护，那么你不需要担心很多问题，因为你对它心知肚明，但同时一个人的力量无法支撑起来大型项目。更多时候，我们需要与其他人合作，共同把项目推进，这意味着我们需要牺牲彼此的一些“自由”，在一些约束框架下进行合作，这就是我今天要提到的工作流。

目前比较流行的工作流规范有：

1. github-flow
2. gitlab-flow
3. git-flow

时间线：git-flow --> github-flow --> gitlab-flow

GitHub-Flow

GitHub flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.

GitHub flow 是轻量级的、基于分支的工作流，它支持团队和项目去进行定期的部署。

GitHub-Flow

我所在的项目组使用的就是GHF（GitHub-Flow），我对它比较熟悉。

GHF的思路很简单，很适合大部分项目组。基本可以用下面一张图来表示：

master --> branch --> pull request --> master

GHF追求的是发散性思维，项目任何时候都可以基于当前的主干创建新的特性分支（feature-branch）去开发，最后合并回主干。周而复始。这个思路很适合开源项目，因为每天都会有不同地区的人去维护一个开源项目，通过GHF，大家都可以把自己的想法实现出来，并请求合并到主干，或者开源项目的负责人会按计划确定项目的下一个新特性，来自世界各地的人都可以在特性分支上贡献自己的一份力量。

所以GHF有一个核心要求，就是主干master必须要永远是可运行、可部署状态。这是很合理的，所以没有经过测试或未通过测试的代码是不允许合并到主干的。以前的做法是，针对每一个pull request，项目主要维护者都需要拉取特性分支到本地进行测试，但是现在可以借助CI/CD来自动化完成这一项任务。

优点：

1. 简洁，思路很清晰，只有一个master分支和多个feature分支
2. 以部署为中心，保证每一个特性分支都可以正常运行
3. 支持快速迭代，快速部署，适合需求变化多端的前端项目

工作经验

我所从事的前端项目组常常是同时几个人在开发不同的需求，所以常常是不同的需求对应不同的特性分支，经过开发阶段、体验阶段、测试阶段，最后合并到主干master，再由构建平台基于主干构建出静态资源，最后打包部署到CDN。似乎和GHF不谋而合。

下面是我的一些工作经验总结：

1. 主干master必须是可部署状态，避免下一个特性分支是不可运行的状态
2. 每一个合并回主干的特性分支也必须是可部署状态
3. 多人合作是无法避免冲突，所以遇到冲突的时候，切换到特性分支，然后merge origin master分支，解决完冲突后再次请求合并到主干
4. 每一个特性分支经过测试后都可以合并到主干，合并到主干后都可以被删除掉，而且建议删除掉，这样确保项目的分支尽可能简洁，不需要顾虑这个特性分支以后还有没有用
5. 项目部署到线上并不意味着结束，一些意想不到的bug还是会发生的，这个时候并不需要也不推荐在之前的特性分支上修复这个bug，可以新建一个修复分支，你可以取名为fix/xxx之类的，按照团队规范来就好，然后快速修复这个bug并重新部署到线上
6. 修改公共基础库和修复bug的分支请求合并到主干，都需要另一个开发者来review代码，这样可以尽可能减少“翻车”事件

我们需要确定一件事，就是我们所做的一切都是为了效率，我是指团队效率，而不仅仅是个人效率。而引入GHF，可以帮我们隔离团队里不同维度的代码，减少代码摩擦。工程化的目的就是隔离变化，沉淀共识。

---

GitLab-Flow

GitLab-Flow可以算是GitHub-Flow的一个升级版，在原有的逻辑上，多了两个分支，Pre-Production分支和Production分支。

GitLab-Flow

GitHub-Flow适用于线上版本和master版本一致的情况，换句话说，它是基于master分支“持续发布”的，任何需要快速迭代的场景都适合，比如前端和后端，都可以开发新功能或者修复bug后合并到主干，然后走构建发布流程就可以同步到线上了，这很方便。

但是对于移动端来说，就不一样了，因为app发布是需要审核周期的，为了让项目继续向前推进，我们需要另外的分支来应付审核周期。master分支继续跟随需求，而“发布”分支对应每一次上线，可以保证master即使新合并了特性不会影响到“发布”分支。

---

Git-Flow

Git-Flow算是最早出现的工作流，它包含了项目完整的生命周期，更严谨，当然也相对复杂了一些。可以用一张图来辅助说明：

Git-Flow

它基于两个长期存在的分支：

1. master，具有多个tag，是develop分支上经过开发、测试后稳定发布的版本，用于发布
2. develop，是自动构建分支，所有的feature分支的代码完成后会合并到develop

其他三个分支，在完成任务后会被删除：

1. feature branches，从develop拉取，为即将发布的版本开发新功能，最终合并回develop
2. hotfix，从master拉取，以便快速修复线上问题，修复完成后合并到develop和master
3. release branches，从develop拉取，包含所有新功能和必要的修复，并且是彻底测试过的，会合并到master和develop

比较适合客户端开发。Git-Flow不仅是一套规范，也是一套工具，目前流行的是avh版本的git-flow。

---

参考：

GitHub Flow​guides.github.com gitflow & github flow & gitlab flow​juejin.im GitLab Flow​about.gitlab.com 4 branching workflows for Git​medium.com 嘟嘟：Git flow Github flow Gitlab flow 抽象模型​zhuanlan.zhihu.com

石墨文档-GIT/GIT-FLOW​shimo.im