> For the complete documentation index, see [llms.txt](https://yangsx95.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yangsx95.gitbook.io/notes/version-control/git/git-gong-zuo-liu.md).

# Git工作流

## Git Flow

参考： <https://nvie.com/posts/a-successful-git-branching-model/>

![file](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-2c45ca461217de790d0f0160f7ea9d3f079990c0%2Fimage-1595153244285.png?alt=media)

Git Flow 分为两个长期分支和三个短期分支：

* 长期分支： master、develop
* 短期分支： features、release、 hotfix

长期分支会跟随项目的生命周期，自创建时就存在，项目删除才会被删除，短期分支则是为了完成某一特定的功能需求临时创建的。

***

**Git Flow 流程**:

* 项目经理在远程仓库创建了一个新的项目
* git为其自动创建了一个master分支
* 紧接着，项目经理通过master分支，构建了一个develop分支，用于开发人员开发
* 项目经理在devlop上将项目骨架提交
* 项目经理同时针对产品以及业务人员提出的功能以及需求，确定版本v1.0
* 通过develop分支构建features分支，比如 features/login, features/orders，或者根据需求编号来 features/20200722111, features/20200722112
* 开发人员根据自己所需要开发的功能或者需求，拉取对应的features分支，并进行开发，并可以随时将代码提交到对应的features分支上
* 当功能开发完毕后，程序员手动将features分支的内容合并到develop分支上
* 这样，develop分支完成了对v1.0新功能的汇总
* 这时，项目开始计划上线，这时项目经理由develop分支创建一个releasev1.0分支（预发布分支），并将release分支打包到测试环境，用于预发布项目版本1.0，并提供给测试人员进行测试
* 如果测试人员在测试过程中，发现了一些不影响业务以及流程的小bug，开发人员将会直接在release分支上进行bug修复提交，并打包到测试环境。修复完成后再次合并到develop分支上。
* 测试完毕后，将会再次将代码发布到灰度环境中测试，
* 当login功能需要上线时，项目经理会将 features/login 分支合并到develop分支上，此时要保证代码逻辑大体正确，代码逻辑符合业务，测试人员将会在develop分支上进行测试
* 如果在测试过程中，发现了一些bug，开发人员将会继续在features分支上修改，然后合并到develop分支上
* 测试人员测试完成后，代码各项完成验证，项目经理将release分支合并到master分支上，并给此次合并增加一个tag1.0
* 持续集成工具发现master分支上的提交，开始进行自动打包部署
* 上线完毕，项目经理将临时分支 features、release删除
* 项目在生产环境上运行，客户反映了紧急的线上问题，从新提交新的features已经来不及，这时，项目经理直接从master分支构建一个hotfix分支，并交予开发人员快速修复，修复完毕后，再将hotfix直接合并到master与develop分支上。打包master分支修复bug。

**各个分支说明**：

* master分支：用于上线发布版本的分支，也是存储生产代码的分支，由develop分支合并，每次合并都会打一个版本tag。
* develop分支：开发分支，用于开发人员合并功能代码的分支。
* feature分支：功能分支,每次有新的功能或者需求需要开发，会首先创建一个feature分支，分支命名为 feature/功能名称，或者 feature/需求编号，开发完成后，通过合并develop进行测试。
* release分支：预发布分支，在合并master分之前，会合并到预发布分支进行测试，release分支代码常打包于准生产环境。
* develop开发分支：开发分支，主分支至于用发布，而开发分支用户合并开发代码，视作新功能的集合。
* release预发布分支：在合并master分之前，会合并到预发布分支进行测试，release分支代码常打包于测试环境。
* feature功能分支：每次有新的功能或者需求需要开发，会首先创建一个feature分支，分支命名为 feature/功能名称，或者 feature/需求编号，开发完成后，合并到develop分支。
* hotfix热修复分支：当生产上出现紧急bug需要修复时，使用hotfix/bug编号 命名一个新的修复分支，通过合并develop在测试环境测试，上线则是直接合并到master分支上（所以叫hot）

**缺点**：

* 流程复杂，操作繁琐
* 发布版本需要预先确认版本功能，不能对需求随时发布

## Github Flow

![file](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-ceaac7676d31f126e9b3e878f3e52440b351c1a1%2Fimage-1595486463725.png?alt=media)

Github Flow 相比于Git Flow就很简单，长期分支只有一个master分支，当有需求或者bug需要修复的时候，就从master中拉取一个分支（不区分功能分支合补丁分支）。当分支开发完成并且测试完成后，再合并到master分支中，部署完毕，将临时分支删除。

**优点**：

* 简单易用
* 适合持续发布的产品

**缺点**：

* 对程序员的素质要求较高（由分支直接合并到主分支发布）

## Gitlab Flow

Gitlab Flow 是 Git Flow 与 Github Flow的结合，他吸取了两者的优点，是gitlab.com推荐的做法。

### 上游优先（upstream first）

只存在一个主分支master，是其他分支的上游，只有上游分支采纳代码变化，才能应用其他分支。比如按照环境来拆分，开发环境就是master分支，开发环境测试完毕后，如果没有问题，才会合并到准生产分支，准生产分支测试没有问题将会发布到他的下游生产分支。

### 持续发布

![file](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-79749e7099ac855008d250387c964f96339c3498%2Fimage-1595489333830.png?alt=media)

除了master分支外，建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境" 的分支是production。

当有新需求或者bug出现时，先建立一个功能分支，修改完成后，将分支合并到develop分支上。测试通过后，再将其放到准生产分支上测试，如果准生产分支上没有问题，则将生产分支与准生产分支同步。

> 只有紧急情况，才允许跳过上游，直接合并到下游分支。

### 版本发布

![file](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-64ae79d73868afd1c4762ea45f2fa2721c29259d%2Fimage-1595489853113.png?alt=media)

对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。