最常用的GIT操作实战场景化讲解（2）

上篇博客从代码仓库clone，到基本的分支创建，代码提交，代码更新等对git的初级使用做了基本的介绍，一下将对其他几个比较场景的场景进行讲解。

场景五：使用cherry pick进行不同分支之间的代码反合

不同分支之间的代码反合很常见，比如在已经外发的维护分支上解决了一个产品问题，后续该问题肯定是要反合到当前的开发分支中来的，因为当前的开发分支肯定也带有这个问题。

最常见的当然是人肉反合了，把另一个分支的用代码比对工具在当前开发分支上改过来再提交一次，这样做对于简单一点的提交还好，复杂一点的就有可能引入问题。而使用cherry pick则可以直接见代码提交到需要的分支，避免了手工合入。

可以看到之前的这个分支有一个我们的测试提交，我们再以它提交前的一个节点拉取一个分支

 可以看到这这个分支上我们是看不到刚才那个改动的

 我们需要再cherryPick的分支上合入刚才的改动，那么首先将分支切换到准备合入代码的分支

 然后我们使用小乌龟打开日志，默认是打开当前分支的日志，点击这个分支名 可以切换查看不同分支的log，点击它我们切换到有那个提交的日志分支日志

此时我们可以选中需要合入的commit提交记录，可以选中多条，右键就有一个cherr pick，

 然后再弹出的界面点击continue，完成后再查看cherryPick这个分支的log

你会发现这给commit已经到我们新的这个分支上来了。

 

 场景六：使用git rebase合并本地的多个commit为一个commit

再上个场景中我们已经体验到git的强大之处，那么为了便于我们不同分支之间能更方便的cherry pick，其实是提倡大家一个完整的功能尽量再一个commit内提交，不然cherry pcik的时候要需要同时去选择多个commit，那么还是会有可能有遗漏的情况。

在平时开发的过程中，我们本地可能再做一个特性自测的时候会发现问题，多次修改代码确实会有多个commit的情况，那我们要做的就是再推送到远端之前将他们合并掉即可对外只体现一个commit。

可以看到我本地为了做测试提交这个特性总共提交了3个相关的commit，如果最后把三个提交一起推送到dev上，一个是以后cherry pick的时候要同时选三个不方便，还有就是这里面可能有改错有改回来的代码，把这些提交的中间过程也推送到dev上去也显得太傻了。

 这里推荐使用git bash来操作，我们先改动最后的三次提交，那么我们需要将git的索引指向到他们的前一次上去也是就更新readme的那一次提交，我们查到它的提交hash

 

执行git rebase -i xxxx 来使git回退到某个节点的状态，执行后会出现一个vi编辑窗口，已经看到我们需要操作的那三条记录了，测试提交是最早的一次，然后是测试提交2222，最后是测试提交3333，这个顺序也是和我们提交的时间轴是一样的，下面的注释也介绍了如果我们先把后面的合入到前一次提交里面我们应该是用s

 

那么修改好应该是这样的，最早的那个提交记录继续使用pick提交，后面的一次使用s合入到前此提交中去，vi 输入wq保存

 

 保存后会有一次重新改写提交记录的机会，可以自由修改

 那我们把其他两次的提交记录都注释掉，并把最上面的改为提交测试合并成功，wq保存

 现在再去查看log会发现之前的三条已经合并为我们最后的一条commit了

 以上是针对你本地完全没推送过远端的情况，如果你本地有些改动已经push过，那你再rebase之后再去推送的时候有可能会给你提示错误，那是因为远端已经没有和你保持一直了，你需要用git push -f 强制将本地的改动推送到远端即可，此时远端的会完全与你本地保持相同。所以强推对于master和dev分支来说要很谨慎，因为是用本地代码强制覆盖远端，很容易把别人的代码给回退，但你自己的远端分支就你自己再用，所以来说不会有问题。 也提醒大家基本你有master和dev的直接提交权限也还是别轻易用，还是拉自己的分支进行开发跟稳妥。

场景七：多提交或提交错了一个文件该怎么处理

当然你可以可以修改正确以后再提交一次，然后使用git rebase将你的两次记录合并为一次，以便于隐藏你的一次愚蠢的提交（实际上git rebase有一个方法是可以让你修改后提交的），但是还有一个方法可以使用让你像拥有月光宝盒一样再来一次。

再git bash中使用git reset 即可

 比如再这次提交中我们把init.sql的内容误提了，我们想再来一次

那执行git reset HEAD^ 即可 HEAD表示当前最新节点HEAD^表示上一次提交节点，我们只需要让状态回退到上一次提交的状态就可以了

 执行完我们发现日志中已经看不到之前的那次提交记录了，而且本地两个文件的修改状态也恢复了，那赶紧把init.sql还原了再一次提交即可，这样就又一次避免被人发现一次愚蠢的提交了

 

场景八：强制让本地代码回滚到上一个提交的版本

其实这个用法和上一条类似，但又有一点差别，上一个场景中回退过来的代码有一部分是你需要的，你只要把错误的那部分剔除就可以了，但如果你即想放弃这次提交记录，也想让你本地的文件回滚到上一个提交的内容放弃你的修改

只需要再上一条命令执行时加上 git reset --hard HEAD^ 这样不仅提交记录没了连这两个文件内容也完全回滚到你修改之前的样子

所以这个命令也是高危命令，他会放弃你本地对文件的修改，让他们和上次提交内容保持一致，执行需要谨慎

其实也就是git reset mix和hard的区别，git reset有三种回退方式 soft ，mix ，hard，如果不指定的话默认是mix也就是场景七的那种状态，如果指定为hard则会放弃你本地的修改，soft只回退了提交记录，但是index区没有回退，其实可以用来修改log使用。

总结

还有一些小tips就是你的本地分支再开发特性之前，还是经常要使用git pull origin dev 和dev分支保持同步，因为团队内都是以dev分支为基础的，你需要及时获取别人的修改，以防止不必要的冲突。尤其是当你的改动很大范围的时候，你在预感到你本地改了这么多有可能会产生冲突的时候，在提交前一定先pull一次dev，保证让冲突先冲突在你本地，解决完毕在推送远端，本地的冲突解决起来至少是比远端的冲突要方便一些。

以上就是针对几个经常使用的场景，提供了一些操作思路，可以让你再不懂git更多的原理的情况下轻松应对日常开发中遇到的实际问题，先学着怎么去用，用一段时间再去看看git原理可能会更容易明白一些

后面有空我们在详细探讨一些git的基本原理知识