Git分支管理策略
- - 阮一峰的网络日志如果你严肃对待编程，就必定会使用" 版本管理系统"（Version Control System）. 眼下最流行的"版本管理系统"，非 Git莫属. 相比同类软件，Git有很多优点. 其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便. 有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用.
Git_014：最佳敏捷分支策略
标签：
Git
| 发表时间：2019-12-02 10:06 | 作者：[email protected] (Unknown)
出处：http://maping930883.blogspot.com/
目前业界有三种分支策略：Git Flow，Github Flow，Gitlab Flow，它们都是采用"功能驱动式开发"（Feature-driven development，FDD）。所谓 FDD，指的是需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（bugfix 或 hotfix branch）。完成开发后，该分支就合并到主分支，然后该分支被删除。
在分析了三种分支策略后，笔者发现三种策略都有某些缺陷，不能完全满足敏捷开发、持续集成、持续部署的要求。
为此，笔者提出最佳敏捷分支策略。
1. 主分支
代码库有两个主分支作为常设分支。
1.1 master 分支
master 分支用于日常开发，存放最新的代码。
master 分支对应测试环境，一套代码版本至少需要搭建两套测试环境，分别用于系统测试（由测试人员测试）和验收测试（由业务人员测试）。
release 分支用于跟踪线上版本，存放所有对外正式发行的版本。
release 分支对应生产环境。
所有测试通过后，从 master 分支创建 release 分支，格式型如 release/1.0，同时在该 release 分支上打 Tag，格式型如: 1.0，注意前面不要加 v，v1.0 不符合习惯。
如何保护 release 分支❓
2. 临时分支
feature 分支是功能分支，用于开发各个功能模块，格式型如 feature/。
开发人员领取各个功能任务后， 从 master 分支创建各自的 feature 分支，通过单元测试和集成测试（由开发人员测试）后，最终合并到 master 分支。
所有 feature 分支都合并到 master 分支后，创建系统测试环境，由测试人员进行系统测试；创建验收测试环境，由业务人员进行验收测试。
2.2. bugfix 分支
bugfix 分支是补丁分支，用于修复在测试环境中测试出来的各个 bug，格式型如 bugfix/。
在测试环境中测试出来的 bug，由开发人员领取任务， 从 master 分支创建各自的 bugfix 分支进行修复，开发人员需要为每个 bugfix 单独编写单元测试和集成测试，测试通过后，最终合并到 master 分支。
2.3. hotfix 分支
hotfix 分支是热补丁分支，用于修复在生产环境中发现的各个 bug，格式型如 hotfix/。
hotfix 分支对应准生产环境，一套代码版本至少需要搭建两套测试环境，分别用于系统测试（由测试人员测试）和验收测试（由业务人员测试）。
在生产环境中发现的 bug，由开发人员领取任务， 从当前发现问题的 release 分支创建各自的 hotfix 分支进行修复，开发人员需要为每个 hotfix 单独编写单元测试和集成测试，
所有测试通过后，将 hotfix 分支合并到 master 分支，然后创建 release 分支，格式型如 release/1.0.x，同时在该 release 分支上打 Tag，格式型如: 1.0.x，注意前面不要加 v，v1.0 不符合习惯。
参考文献：
1. https://gist.github.com/digitaljhelms/4287848
2. http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
3. https://www.cnblogs.com/doit8791/p/10147321.html
4. https://blog.csdn.net/hu_zhiting/article/details/95030586
5. http://www.ruanyifeng.com/blog/2012/07/git.html
6. https://www.atlassian.com/blog/git/simple-git-workflow-is-simple
7. https://mohamedradwan.com/2018/01/08/promoting-your-application-deployment-to-different-environments-from-branches-with-and-without-feature-toggle/
在分析了三种分支策略后，笔者发现三种策略都有某些缺陷，不能完全满足敏捷开发、持续集成、持续部署的要求。
为此，笔者提出最佳敏捷分支策略。
1. 主分支
代码库有两个主分支作为常设分支。
- master
- release
1.1 master 分支
master 分支用于日常开发，存放最新的代码。
master 分支对应测试环境，一套代码版本至少需要搭建两套测试环境，分别用于系统测试（由测试人员测试）和验收测试（由业务人员测试）。
如何保护 master 分支❓
1.2 release 分支 release 分支用于跟踪线上版本，存放所有对外正式发行的版本。
release 分支对应生产环境。
所有测试通过后，从 master 分支创建 release 分支，格式型如 release/1.0，同时在该 release 分支上打 Tag，格式型如: 1.0，注意前面不要加 v，v1.0 不符合习惯。
如何保护 release 分支❓
2. 临时分支
- feature
- bugfix
- hotfix
feature 分支是功能分支，用于开发各个功能模块，格式型如 feature/。
开发人员领取各个功能任务后， 从 master 分支创建各自的 feature 分支，通过单元测试和集成测试（由开发人员测试）后，最终合并到 master 分支。
所有 feature 分支都合并到 master 分支后，创建系统测试环境，由测试人员进行系统测试；创建验收测试环境，由业务人员进行验收测试。
2.2. bugfix 分支
bugfix 分支是补丁分支，用于修复在测试环境中测试出来的各个 bug，格式型如 bugfix/。
在测试环境中测试出来的 bug，由开发人员领取任务， 从 master 分支创建各自的 bugfix 分支进行修复，开发人员需要为每个 bugfix 单独编写单元测试和集成测试，测试通过后，最终合并到 master 分支。
2.3. hotfix 分支
hotfix 分支是热补丁分支，用于修复在生产环境中发现的各个 bug，格式型如 hotfix/。
hotfix 分支对应准生产环境，一套代码版本至少需要搭建两套测试环境，分别用于系统测试（由测试人员测试）和验收测试（由业务人员测试）。
在生产环境中发现的 bug，由开发人员领取任务， 从当前发现问题的 release 分支创建各自的 hotfix 分支进行修复，开发人员需要为每个 hotfix 单独编写单元测试和集成测试，
所有测试通过后，将 hotfix 分支合并到 master 分支，然后创建 release 分支，格式型如 release/1.0.x，同时在该 release 分支上打 Tag，格式型如: 1.0.x，注意前面不要加 v，v1.0 不符合习惯。
参考文献：
1. https://gist.github.com/digitaljhelms/4287848
2. http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
3. https://www.cnblogs.com/doit8791/p/10147321.html
4. https://blog.csdn.net/hu_zhiting/article/details/95030586
5. http://www.ruanyifeng.com/blog/2012/07/git.html
6. https://www.atlassian.com/blog/git/simple-git-workflow-is-simple
7. https://mohamedradwan.com/2018/01/08/promoting-your-application-deployment-to-different-environments-from-branches-with-and-without-feature-toggle/
相关 [git 分支 策略] 推荐：
Git 分支管理策略与工作流程
- - IT瘾-devGit 是目前世界上最先进的分布式版本控制系统. 它使我们更方便的跟踪，管理和组织代码. 也帮助了我们更好的与其他开发者进行协作开发. 协作开发必须有一个规范来约束各个贡献者的行为. 这个规范就是 Git 工作流程(Git Workflow)，也为我们规范各个分支管理策略等行为. Git 工作流程是有关如何使用 Git 以高效协作开发的规则或策略建议，下文这些常见工作流程只是作为指导参考，这些工作流不是一成不变的，我们应该根据自己的项目选择或制定合适自己的工作流.
Git 分支设计规范
- - 掘金后端这篇文章分享 Git 分支设计规范，目的是提供给研发人员做参考. 规范是死的，人是活的，希望自己定的规范，不要被打脸. 在说 Git 分支规范之前，先说下在系统开发过程中常用的环境. DEV 环境：用于开发者调试使用. FAT 环境：功能验收测试环境，用于测试环境下的软件测试者测试使用. UAT 环境：用户验收测试环境，用于生产环境下的软件测试者测试使用.
git分支的管理流程
- - 掘金 后端这是我参与「掘金日新计划 · 6 月更文挑战」的第2天， 点击查看活动详情. 现在大部分公司都是使用git来管理代码的，我今天分享一下我们司后端代码的git管理流程吧. 先拉取最新的develop分支的代码. 确保develop上一个版本的代码已经合并到test分支了. 基于develop分支创建自己的功能开发分支.
多分支开发策略
- - CSDN博客研发管理推荐文章ü 功能开发 (开发人员). ü bug修复，包括测试版本的bugfix和生产版本的hotfix (开发人员). ü 版本集成，包括发布测试版本和生产版本 (项目经理). ü 版本测试 (测试人员). ü 保证bug修复与功能开发并行，不会出现堵塞情形. ü 保证可以快速版本集成. 实现方式就是多分支 + 里程碑标记.
Git基础
- Wolf - 潘魏增上个月末在公司内部作了一次《Git基础》的主题分享. 这里把分享内容公布出来，希望对一些朋友有用. 如果之前没有接触过Git，wikipedia上面已经有非常好的介绍. pdf格式：http://panweizeng.com/download/git-basics-meituan.pdf. keynote格式：http://panweizeng.com/download/git-basics-meituan.key.
Git_014：最佳敏捷分支策略
- - 心有猛虎，细嗅蔷薇目前业界有三种分支策略：Git Flow，Github Flow，Gitlab Flow，它们都是采用"功能驱动式开发"（Feature-driven development，FDD）. 所谓 FDD，指的是需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（bugfix 或 hotfix branch）.
Git-rebase 小筆記
- lepture - YORKXIN×YORKXIN最近剛好有個機會整理很亂的 Git commit tree，終於搞懂了 rebase 的用法，筆記一下. 大家都知道 Git 有個特色就是 branch 開很大開不用錢，但很多 branches 各自開發，總要在適當時機 merge 進去 master. 看過很多 git 操作指南都告訴我們，可以妥善利用 rebase 來整理看似很亂或是中途可能不小心手滑 commit 錯的 commits ，甚至可以讓 merge 產生的線看起來比較簡單，不會有跨好幾十個 commits 的線.
Git 简明教程
- satoru - python.cn(jobs, news)Git 是一款强大的分布式版本控制系统.在他的官网可以找到已经有很多著名的项目正在使用. Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another.
git架构图解
- - CSDN博客研发管理推荐文章 最近又遇到Git了，发现网络上Git的资料确实不咋滴，难懂不全面. 至于Git是什么我就不多说了，相比svn上手确实更难. 与svn集中版本库相比较，Git被称作分布式版本库，在分布式的版本库中任何一个库都可以作为中心库看待. 如果说svn是颗树，那么Git就像一张网. Svn在每个目录都有一个.svn文件夹存放信息，而git只在根目录才有，这就决定了svn可以单独拉取某个子目录或者某个文件，而git需要全部拉取.