git rebase/revert/reset 命令用法及场景

全文有描述不正确或表达不清晰的地方，欢迎评论指正！

git rebase

用法

// 当前处于dev分支
git rebase origin/release

场景

一般用在解决开发分支合并入主分支的冲突上。或者说在开发期间，定期更新本地开发分支上的主分支代码。

使用git rebase使得冲突问题暴露在merge之前，并且最好是在自测之前完成一次rebase操作，这样可以保证自己自测的时候是基于最新的主分支代码，避免合并入主分支之后，由于主分支的一些改动，导致自己的功能出现问题。

例如：主分支修改了A model类，删除了一个属性，而开发分支使用了该model类，就会出现打包失败的问题。

注意事项：

其实git rebase 有另一种操作就是将主分支合并到开发分支，git merge，最终代码的结果是一致的。两种的区别是：

1. git merge会多一条commit记录：merge 主分支 into 开发分支。按规范流程来看，主分支合并入开发分支的这种记录是不合理的，只能是开发分支合并入主分支。但是git merge 不会改变本地的commit记录（commit号），所以merge完可以直接push到远程。
2. git rebase不会多commit记录，会将本地开发分支和主分支commit不一致的所有commit，提交到主分支的最新commit之后（不会改动主分支）。这样下次合并入主分支的时候就不会有冲突了（冲突会在rebase的时候就解决掉了）。但是git rebase会改变commit号，会导致push的时候可能需要push -f 强制推到远程。
3. 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）。

一般主分支上，临时需要剥掉一个功能之类的时候，会从主分支拉一个开发分支，执行revert，再重新合并到主分支上。总体而言，git revert 是一个安全的撤销更改的方法，因为它不会修改历史记录，而是添加新的提交以反转之前的更改。

注意事项：

1. 有一个问题就是，如果执行过revert之后，下一次，想要重新上此功能的时候，原先的开发分支，需要重新commit一下，不然相同的commit由于在release上本来就有了，会导致虽然merge了，但是没有任何变更。（git merge比较的就是是否存在不同的commit hash值）
2. 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到主分支之前，我会整理自己开发分支上的代码。

例如：

1. 某次开发过程中，我可能会开发的过程中定期commit一下我的代码，但是这个commit可能纯粹就是暂存，然后一次功能可能会有n个不规范的commit，那么在最后我开发完成之后，我会soft reset本次开发的多次commit，然后重新规范的commit 一次。
2. 可能我在第一点基础上会做一些代码优化之类的改动，但是担心代码优化会导致我功能异常，就会在先commit再改动，改动玩没有问题了，会soft reset成一次commit。

其实对我来说reset就是我整理代码的一个工具，能够让我的commit最终变成清晰简洁的功能性commit记录，保证最后合并到主分支之后，主分支的git记录也是清晰简洁的。

注意事项：

1. soft和mixin的区别就是要不要保留暂存区（当前改动且未提交）的代码，我一般是soft，因为我再reset的时候如果暂存区有东西，那一定是我要保留的。大家可以参考自己的实际情况选择。
2. hard reset 我很少用到，基本只有在我明确不需要这个commit 的时候，我才会使用。hard reset之后是不可回溯的，这个commit的修改就真的找不回来了，所以还是得小心使用。
3. 和上面的revert相比，hard reset 虽然确实能够把代码的修改取消掉，但是不能作为剥离主分支代码的方法使用。因为hard reset是删除了commit，但是并没有增加或修改commit，hard reset之后再提merge 到主分支，是不会有任何变化的。因为对于主分支来说，你的所有commit主分支都存在，那么就认为两个分支没有差异。（again：git merge 比较的是两个分支的commit差异）
4. reset之后一般推送都不能直接推送成功，可以在确保无误的情况下，push -f强制推送到远程分支。

其他细节点：

1. git rebase 和 git reset 建议都只在自己的开发分支上使用，不要影响到主分支。
2. 在协同开发的分支上，建议拉出自己的单独分支，进行开发，然后可以使用rebase和reset，最后merge进入协同开发分支。避免因为自己的rebase和reset 影响到所有协同开发的同事。