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 影响到所有协同开发的同事。

你可能感兴趣的:(开发辅助工具,git)