Git分支管理策略：Gitflow思想与实践

Git 分支管理策略 Git 分支管理策略是一种思想，而不是一个工具。它通过利用 Git 创建和管理分支的能力，为每个分支设定具有特定的含义名称，并将软件生命周期中的各类活动归并到不同的分支上。实现了软件开发过程不同操作的相互隔离。 单分支带来的问题包括：混乱的代码版本、冲突严重、无法隔离多人协作的开发环境、try 版本无法隔离、测试和发布版本不稳定、发布当前版本代码冗余、附带非当前版本代码等。 Git 分支管理策略主要分支包括： 1. 发布分支（生产环境）：master（release），主要保存生产环境历史版本，部署线上版本。 2. 开发分支：develop，用于组织和开发（组织清晰的需求版本变化，便于加入新的开发活动）。 3. 功能分支：feature，解决特定的功能需求，或者开发中版本的 bug 修复。 4. 预发布分支（测试环境）：release，用于准备发布的正式版本做集成测试的分支。 5. 修复分支：hotfix，从 master 分支中生出，为紧急修复生产环境中的 bug 而产生。 Git 分支管理策略的合并要求： * 主分支合并请不要使用快速合并方式（--no-ff）。 * 辅助分支合并前必须先自行解决冲突。 * 请求合并到主分支流程规范 rebase 变基原理：首先找到这两个分支的最近共同祖先 C2，然后对比当前分支相对于该祖先的历次提交（C5、C6），提取相应的修改并存为临时文件（C5’、C6’），然后将当前分支指向目标基底 C4，最后以此将之前另存为临时文件的修改依序应用。 Git 分支管理策略的目的： * 向当前开发中的分支引入最新修改。 * 确保在向远程/公共分支推送时能保持提交历史的整洁。 为什么必须要预发布分支？如果当前版本都集中到了 develop 分支，发现了 bug，为什么不在 develop 上直接 fix bug，而要建立预发布分支？为了版本演进。 Git 分支管理策略的使用建议： * 辅助分支合并请用 --no-ff。 * 辅助分支的子功能分支合并请用 --no-ff。 * 辅助分支的修复分支合并使用 ff。