回滚分为两种。
1、包回滚，线上运行的系统，从现在的版本回滚到之前稳定的版本
2、代码回滚，指git分支的游标，从指向当前有问题的版本改动为指向一个改分支历史树上没有问题的版本。这个版本可以是曾经的commit，也可以是新建的commit
代码回滚场景及方式
1、开发环境有一个新分支，共5个提交，回滚最新3个提交。仅影响用户个人
2、本地分支通过reset --hard方式做了回滚，想让远端一起回滚。仅影响用户个人
reset --hard后，push需要增加-f参数
3、线上产品包已经回滚到昨天版本了，昨天发布分支代码也reset --hard 对应的commit了，有问题的commit又逮到发布分支了
集成分支不能使用reset --hard回滚，应该集成分支上新增commit方式进行
4、gitlab上游一个merge请求，已经合并到master了，合并commit有较大质量问题，必须回滚到之前
使用gitlab的合并请求上的revert
5、线上A产品的V6.2包有问题，已经把A产品包回滚到V6.1版本了，发布分支上的代码是否也要回滚
如果回滚后，不是源代码问题，不需要回滚代码。下次上线发布，用来修复刚才线上问题，不用回滚代码。
图中的具体情况信息：
C3 打包并上线，生成线上的版本 V0529，运行正确。
之后 C6 也打包并上线，生成线上版本 V0530，运行一段时间后发现有问题。C4 和 C5 并没有单独打包上线，所以没有对应的线上版本。项
目组把产品包从 V0530 回滚到 V0529，经过定位，V0530 的代码有问题，但短时间不能修复，于是，项目组决定回滚代码。C4 和 C5 没有单独上过线，因此从线上包的角度看，不能回滚到 C4 或 C5，应该回滚到 C3。
考虑到线上包可以回滚到曾发布过的任意一个正确的版本。为了适应线上包的这个特点，线上包回滚触发的代码回滚我们决定不用 一个个 revert C4、C5 和 C6 的方式，而是直接创建一个新的 commit，它的内容等于 C3 的内容。具体回滚步骤：
$ git fetch origin
$ git checkout master
$ git reset --hard V0529 # 把本地的master 分支的指针回退到 V0529，此时暂存区(index)里就指向 V0529里的内容了。
$ git reset --soft origin/master # --soft使得本地的master 分支的指针重新回到 V05javascript:;30，而暂存区(index)变成 V0529的内容。
$ git commit -m "rollback to V0529" # 把暂存区里的内容提交，这样一来新生成的commit的内容和 V0529 相同。
$ git push origin master # 远端的master也被回滚。
6、代码包的回滚在持续交付凭条执行，平带能不能提供代码意见回滚能力
平台能提供最好了
代码回滚原则
集成分支的代码回滚坚决不用reset --hard的方式，原因如下：
1、集成分支的commit是项目阶段性的成果，及时最近的发布不需要commit功能，仍然需要这写commit，以备后续使用
2、开发会基于集成分支上的commit拉取新分支，如果集成分支采用reset的方式清楚，下次其他人会把新分支集成时，会把被清除的commit申请何如
