Git工作流
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
参考： https://nvie.com/posts/a-successful-git-branching-model/
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 相比于Git Flow就很简单，长期分支只有一个master分支，当有需求或者bug需要修复的时候，就从master中拉取一个分支（不区分功能分支合补丁分支）。当分支开发完成并且测试完成后，再合并到master分支中，部署完毕，将临时分支删除。
优点：
简单易用
适合持续发布的产品
缺点：
对程序员的素质要求较高（由分支直接合并到主分支发布）
Gitlab Flow 是 Git Flow 与 Github Flow的结合，他吸取了两者的优点，是gitlab.com推荐的做法。
只存在一个主分支master，是其他分支的上游，只有上游分支采纳代码变化，才能应用其他分支。比如按照环境来拆分，开发环境就是master分支，开发环境测试完毕后，如果没有问题，才会合并到准生产分支，准生产分支测试没有问题将会发布到他的下游生产分支。
除了master分支外，建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境" 的分支是production。
当有新需求或者bug出现时，先建立一个功能分支，修改完成后，将分支合并到develop分支上。测试通过后，再将其放到准生产分支上测试，如果准生产分支上没有问题，则将生产分支与准生产分支同步。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
