推荐的源码管理策略-gitlab flow
文章目录
0x00 写在前面
以 git 为代表的源码管理软件的主要作用之一是方便多人协作,既然有协作就用工作流程。
0x01 gitlab flow 推荐的做法
1. 基础:功能驱动式开发 & 在 feature 分支中进行问题跟踪
当前比较主流的 git 工作流程(git flow、github flow以及 gitlab flow)都基于 功能驱动式开发 以及 在 feature 分支中进行问题跟踪。
其所指其实很简单:明确需求是所有开发的起点,当需求提出时先从主分支拉出功能分支(feature branch)进行开发,待完成开发后,再将该分支就合并到主分支,最后删除该功能分支。
2. (线上)持续发布项目建议使用的 gitlab flow
建议在master分支以外,再建立不同的环境分支。
3. (线下)版本发布项目建议使用的 gitlab flow
对于"版本发布"的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支。
4. gitlab flow 的实践要点
- Use feature branches, no direct commits on master.
- Test all commits, not only ones on master.
- Run all the tests on all commits (if your tests run longer than 5 minutes have them run in parallel).
- Perform code reviews before merges into master, not afterwards.
- Deployments are automatic, based on branches or tags.
- Tags are set by the user, not by CI.
- Releases are based on tags.
- Pushed commits are never rebased.
- Everyone starts from master, and targets master.
- Fix bugs in master first and release branches second.
- Commit messages reflect intent.
0x02 git flow 与 github flow 的缺点
1. git flow 的缺点
- git flow 要求同时维护 develop(用于集成) 和 master(用于预发布) 两个主分支,比较麻烦
- git flow 定义的 hotfix 分支 release 分支与 CI/CD 的理念冲突
2. github flow 的缺点
- 在 github flow 中,只有一个 master 分支使得版本管理、部署管理工作变得复杂