本文主要是介绍git rebase/revert/reset 命令用法及场景，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
全文有描述不正确或表达不清晰的地方，欢迎评论指正！
git rebase
用法
// 当前处于dev分支
git rebase origin/release场景
一般用在解决开发分支合并入主分支的冲突上。或者说在开发期间，定期更新本地开发分支上的主分支代码。
使用git rebase使得冲突问题暴露在merge之前，并且最好是在自测之前完成一次rebase操作，这样可以保证自己自测的时候是基于最新的主分支代码，避免合并入主分支之后，由于主分支的一些改动，导致自己的功能出现问题。
例如：主分支修改了A model类，删除了一个属性，而开发分支使用了该model类，就会出现打包失败的问题。
注意事项：
其实git rebase 有另一种操作就是将主分支合并到开发分支，git merge，最终代码的结果是一致的。两种的区别是：
- git merge会多一条commit记录：merge 主分支 into 开发分支。按规范流程来看，主分支合并入开发分支的这种记录是不合理的，只能是开发分支合并入主分支。但是git merge 不会改变本地的commit记录（commit号），所以merge完可以直接push到远程。
- git rebase不会多commit记录，会将本地开发分支和主分支commit不一致的所有commit，提交到主分支的最新commit之后（不会改动主分支）。这样下次合并入主分支的时候就不会有冲突了（冲突会在rebase的时候就解决掉了）。但是git rebase会改变commit号，会导致push的时候可能需要push -f 强制推到远程。
- git merge和git rebase在解决冲突的结果也是不一致的，git merge会将解决冲突的记录保存在最后一个merge a into b 的commit上。但是git rebase 是会直接改变发生冲突的那一次commit。例如我本地有c=>b=>a=>最新，如果a发生了冲突，那么会直接修改a commit中的代码变动。
git revert
用法
git revert <commit>
场景
用于撤销指定提交的命令，它会创建一个新的提交来取消前一个提交的更改（相当于手动把那一次的提交修改回之前的样子，再提交commit）。
一般主分支上，临时需要剥掉一个功能之类的时候，会从主分支拉一个开发分支，执行revert，再重新合并到主分支上。总体而言，git revert 是一个安全的撤销更改的方法，因为它不会修改历史记录，而是添加新的提交以反转之前的更改。
注意事项：
- 有一个问题就是，如果执行过revert之后，下一次，想要重新上此功能的时候，原先的开发分支，需要重新commit一下，不然相同的commit由于在release上本来就有了，会导致虽然merge了，但是没有任何变更。（git merge比较的就是是否存在不同的commit hash值）
- git revert可以一次性将多次commit撤销掉，可以自行了解一下高级用法。
git reset
用法
// Soft Reset
git reset --soft HEAD^// Mixed Reset
git reset HEAD^// Hard Reset
git reset --hard HEAD^
soft：保留工作区和暂存区的更改，将 HEAD 移动到指定的提交。
mixed：保留工作区的更改，但取消暂存区的更改，将 HEAD 移动到指定的提交。
hard：丢弃工作区、暂存区和历史记录中的更改，将 HEAD 移动到指定的提交。
场景
一般在最终提交merge到主分支之前，我会整理自己开发分支上的代码。
例如：
- 某次开发过程中，我可能会开发的过程中定期commit一下我的代码，但是这个commit可能纯粹就是暂存，然后一次功能可能会有n个不规范的commit，那么在最后我开发完成之后，我会soft reset本次开发的多次commit，然后重新规范的commit 一次。
- 可能我在第一点基础上会做一些代码优化之类的改动，但是担心代码优化会导致我功能异常，就会在先commit再改动，改动玩没有问题了，会soft reset成一次commit。
其实对我来说reset就是我整理代码的一个工具，能够让我的commit最终变成清晰简洁的功能性commit记录，保证最后合并到主分支之后，主分支的git记录也是清晰简洁的。
注意事项：
- soft和mixin的区别就是要不要保留暂存区（当前改动且未提交）的代码，我一般是soft，因为我再reset的时候如果暂存区有东西，那一定是我要保留的。大家可以参考自己的实际情况选择。
- hard reset 我很少用到，基本只有在我明确不需要这个commit 的时候，我才会使用。hard reset之后是不可回溯的，这个commit的修改就真的找不回来了，所以还是得小心使用。
- 和上面的revert相比，hard reset 虽然确实能够把代码的修改取消掉，但是不能作为剥离主分支代码的方法使用。因为hard reset是删除了commit，但是并没有增加或修改commit，hard reset之后再提merge 到主分支，是不会有任何变化的。因为对于主分支来说，你的所有commit主分支都存在，那么就认为两个分支没有差异。（again：git merge 比较的是两个分支的commit差异）
- reset之后一般推送都不能直接推送成功，可以在确保无误的情况下，push -f强制推送到远程分支。
其他细节点：
- git rebase 和 git reset 建议都只在自己的开发分支上使用，不要影响到主分支。
- 在协同开发的分支上，建议拉出自己的单独分支，进行开发，然后可以使用rebase和reset，最后merge进入协同开发分支。避免因为自己的rebase和reset 影响到所有协同开发的同事。
这篇关于git rebase/revert/reset 命令用法及场景的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
