Git - Git 分支管理

Git 三大特色，分支，暂存区，工作流。工作流（Git WorkFlow）不涉及任何命令，表示Git进行软件开发需要遵循的开发流程，通俗一点的称呼就是分支策略。

何谓分支策略
Git的特色之一就是可以灵活的建立分支，因为有分支的存在，才构成了多工作流的特色。事实的确如此，因为项目开发中，多人协作，分支很多，虽然各自在分支上互不干扰，但是我们总归需要把分支合并到一起，而且真实项目中涉及到很多问题，例如版本迭代，版本发布，Bug 修复等，为了更好的管理代码，需要制定一个工作流程，这就是通常意义上的Workflow，也就是我们常说的分支管理策略。

热度最高的分支管理策略

目前使用度最高的工作流前三名分别是以下三种（排名不分先后）：

• Git Flow
• GitHub Flow
• GitLab Flow

其中 Git Flow 出现的最早，GitHub Flow 在 Git Flow 的基础上，做了一些优化，适用于持续版本的发布，而 GitLab Flow 出现的时间比较晚，所以综合前面两种工作流的优点，制定而成的一个工作流。

1，Git Flow

Git Flow是 Vincent Driessen 2010 年发布出来的他自己的分支管理模型，属于强流程性，使用度非常高，比较适合开发技术能力中等的团队作战。

Git Flow 的分支结构很特别，按功能来说，可以分支为5种分支，从5 种分支的生命时间上，又可以分别归类为长期分支和暂时分支，或者更贴切描述为，主要分支和协助分支。

主要分支
在采用 Git Flow 工作流的项目中，代码的中央仓库会一直存在以下两个长期分支：

Master
Develop
其中 origin／master 分支上的最新代码永远是版本发布状态。origin／develop 分支则是最新的开发进度。

当 develop 上的代码达到一个稳定的状态，可以发布版本的时候，develop上这些修改会以某种特别方式被合并到 master 分支上，然后标记上对应的版本标签。

协助分支
除了主要分支，Git Flow 的开发模式还需要一系列的协助分支，来帮助更好的功能的并行开发，简化功能开发和问题修复。协助分支分为以下几类：

Feature Branch
Release Branch
Hotfix Branch
Feature 分支用来做分模块功能开发，建议命名为feature-xxx,模块完成之后，会合并到 develop 分支，然后删除。

Release 分支用来做版本发布的预发布分支，建议命名为 release-xxx。例如在软件 1.0.0 版本的功能全部开发完成，提交测试之后，从 develop 检出release-1.0.0 ,测试中出现的小问题，在 release 分支进行修改提交，测试完毕准备发布的时候，代码会合并到 master 和 develop，master 分支合并后会打上对应版本标签 v1.0.0, 合并后删除自己，这样做的好处是，在测试的时候，不影响下一个版本功能并行开发。

Hotfix 分支是用来做线上的紧急 bug 修复的分支,建议命名为 hotfix-xxx。当线上某个版本出现了问题，将检出对应版本的代码，创建 Hotfix 分支，问题修复后，合并回 master 和 develop ，然后删除自己。这里注意，合并到 master 的时候，也要打上修复后的版本标签。

Git Flow Branching Model

2, GitHub Flow
 

GitHub Flow 是大型程序员交友社区 GitHub 制定并使用的工作流模型，由 scott chacon 在 2011 年 8月 31 号正式发布。因为 Git Flow 对于大部分开发人员和团队来说，稍微有些复杂，而且没有 GUI 图形页面，只能命令行操作，所以为了更好的解决这些问题，GitHub Flow 应运而生了。

GitHub Flow

对比上面那张 Git flow 分支模型图，GitHub flow真的可以称得上简单明了，因为 GitHub Flow 推荐做法是只有一个主分支 master，团队成员们的分支代码通过 pull Request 来合并到 master 上。这种分支策略适合团队开发技术比较高的团队使用，否则就是no zuo no die。

GitHub Flow 模型简单说明

1. 只有一个长期分支 master ,而且 master 分支上的代码，永远是可发布状态,一般 master 会设置 protected 分支保护，只有有权限的人才能推送代码到 master 分支。
2. 如果有新功能开发，可以从 master 分支上检出新分支。
3. 在本地分支提交代码，并且保证按时向远程仓库推送。
4. 当你需要反馈或者帮助，或者你想合并分支时，可以发起一个 pull request。
5. 当 review 或者讨论通过后，代码会合并到目标分支。
6. 一旦合并到 master 分支，应该立即发布。

其中最有特色的就是pull request，后来GitLab Flow也受此启发有了Merge Request。

3, GitLab Flow

GitLab Flow是 GitLab 的 CEO Sytse Sijbrandij 在 2014 年 9月 29 正式发布出来的。因为出现的比前面两种工作流稍微晚一些，所以它有个非常大的优势，集百家之长，补百家之短。
GitLab 既支持 Git Flow 的分支策略，也有 GitHub Flow 的 Pull Request（ Merge Request ） 和 issue tracking。

针对GitHub里面只有一个Master分支的情况，从需要发布的环境的角度出发，添加了 pre-production 和 prodution 分支都对应不同的环境，这个分支策略比较适用服务端，测试环境，预发环境，正式环境，一个环境建一个分支。

environment_branches
 

这里要注意，代码合并的顺序，要按环境依次推送，确保代码被充分测试过,才会从上游分支合并到下游分支。除非是很紧急的情况，才允许跳过上游分支，直接合并到下游分支。这种规则称之为 “upstream first”，也就是 “上游优先”。

在 Git Flow ,版本记录是通过 master 上的 tag 来记录。发现问题，创建 hotfix 分支，完成之后合并到 master 和 develop。

在 GitLab Flow ，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。发现问题，就从对应版本分支创建修复分支，完成之后，先合并到 master，才能再合并到 release 分支，遵循 “上游优先” 原则。

release_branches
 

GitLab中的Merge Request（MR，合并请求）是作为编码协作及版本控制平台的 GitLab 的基础功能。就和它的命名一样：是一个将一个分支合并到另一个分支上的请求。

通过 GitLab 的 Merge requests，我们可以：

• 对比两个分支的差异
• 逐行地去 Review 和讨论改动内容
• 将 MR 指派给任何已注册用户，并且可以任意多地改变受理人
• 通过 UI 界面去解决冲突

分支命名

feature分支：

以feature/<姓名-功能名>形式命名，如feature/lj-login，表示由lj负责的登录功能开发。

在新功能开发时，可以从master或develop分支派生出一个新的feature分支。开发完成后，应将该分支合并至develop进行测试。测试通过后，可删除该feature分支。

develop分支：

作为唯一的开发分支，用于集成功能并进行测试。作为集成和测试的枢纽，develop 分支汇聚了开发者的迭代成果。在develop上，产品虽可能尚缺某些功能模块，但已有功能必须完整。develop的更新需通过与其他分支的合并进行，直接修改是严禁的。

这个分支可以用来生成代码的最新隔夜版本（nightly）。

release分支：

预发布分支，用于发布前的最后测试。举例：release-3.1。

当项目准备就绪，从develop派生出一个release分支进行质量把控、bug修复及文档生成。完成这些发布前任务后，release需合并至master并打上版本号标签，同时将自release分支以来的变更合并回develop，最终删除release分支。

master || main分支：

代码库有且仅有一个主分支，所有提供给用户使用的正式版本，都在这个主分支上发布。包含稳定的、已发布的生产代码，通常也是保护分支。

这里存储着正式发布的迭代成果，要求产品随时可部署。master的内容更新同样需通过合并其他分支进行，直接修改亦被禁止。

Master分支上打tag。

hotfix || fix分支：

当出现紧急问题时，基于已发布的master之上，进行问题修复。

若master中的产品出现紧急bug，则从该分支创建一个hotfix分支进行修复。修复完毕后，hotfix需合并至master和develop，并为master添加新版本号标签，最后删除hotfix分支。

举例：

Release分支操作

git checkout master
git merge release/release-name
git tag -a v1.0.0 -m "Release version 1.0.0"

git checkout develop
git merge release/release-name
git branch -d release/release-name

Hotfix分支操作

git checkout master git merge hotfix/hotfix-name git tag -a v1.0.1 -m "Hotfix version 1.0.1" git checkout develop git merge hotfix/hotfix-name git branch -d hotfix/hotfix-name

版本号的命名规则

命名规则：vx.y.z

x： 大版本号，有重大功能发布时升位。
y：中版本号，增加新功能或功能优化改进时升位。
z：小版本号，有hotfix时升位。

参考：

Git 分支管理指南：如何应对分支混乱？

基于 Git 的分支策略，你值得一看！ - 知乎