推荐的源码管理策略-gitlab flow

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/xiaosongluo/article/details/86675493

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 的实践要点

1. Use feature branches, no direct commits on master.
2. Test all commits, not only ones on master.
3. Run all the tests on all commits (if your tests run longer than 5 minutes have them run in parallel).
4. Perform code reviews before merges into master, not afterwards.
5. Deployments are automatic, based on branches or tags.
6. Tags are set by the user, not by CI.
7. Releases are based on tags.
8. Pushed commits are never rebased.
9. Everyone starts from master, and targets master.
10. Fix bugs in master first and release branches second.
11. 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 分支使得版本管理、部署管理工作变得复杂

0x03 参考

• Introduction to GitLab Flow
• A successful Git branching model
• Understanding the GitHub flow
• The 11 Rules of GitLab Flow
• Git 工作流程