[开发工具] git常用命令

一种就是你本地的代码和远端代码没有冲突的情况下，并且你本地有新增提交，那么你可以仍然执行上述命令，这样就会直接将当前本地分支合远程分支关联上，同时把你的改动提交上去。
另一种就是本地分支和远端分支存在冲突，这个时候你执行上述命令就会出现提示冲突，那么接下来就需要你先把远端当前分支的代码拉下来，解决一下冲突了，就需要用到 git pull 命令了。

git pull

通常情况下，如果当前分支已经和远端分支建立了联系，那么我们想要合并一下远端分支，只需要执行 git pull 就好了，不用带其他参数，但如果和上面提到的 git push 时产生了冲突，还没有建立联系的时候，我们就需要指定需要拉取哪个分支的代码下来进行合并了。

拉取指定远端分支合并到本地当前分支：git pull origin branch1

这里的 origin 是我们对远端仓库的命名，想改也是可以的，不过一般都是用的 origin。

回到上面提到的冲突问题，我们可以直接使用 git pull 然后指定合并当前本地分支想要建立联系的远程分支，然后本地解决一下冲突，然后提交一下改动，再执行 git push --set-upstream origin branch1 命令就大功告成了。

git fetch

了解完上面描述的 git pull，命令之后，其实这个命令也很好理解了，特定时候，可能我们只是想把远端仓库对应分支的变更拉到本地而已，并不想自动合并到我的工作区（你当前正在进行代码变更的工作区），等晚些时候我写完了某部分的代码之后再考虑合并，那么你就可以先使用 git fetch。

fetch 完毕之后，我提交了自己当前工作去的变更到本地仓库，然后想合并一下远端分支的更改，这个时候执行一下 git merge origin/[当前分支名]（默认一般是用 origin 表示远端的分支前缀）即可。

git merge

合并指定分支代码到当前分支。一般来说，我们用的比较多的场景可能是，远端仓库 master 分支有变更了，同时这个时候我们准备提 MR 了，那么就需要先合一下 master 的代码，有冲突就解决下冲突，那这个时候我们可以做以下操作：

切到 master 分支，git pull 拉一下最新代码
切回开发分支，执行 git merge master 合并一下 master 代码?

git log

当前分支的提交记录信息,比如 commitId 和提交的时间描述等等

git reset?

git reset [--soft | --mixed | --hard] [HEAD]

?关于 HEAD：

HEAD 表示当前版本
HEAD^ 上一个版本
HEAD^^ 上上一个版本
HEAD^^^ 上上上一个版本

?git reflog

用来查看你的所有操作记录。(reset?回滚掉的?记录通过git log看不到，可以通过git reflog查看全部)

??git revert

当然了，如果是针对 master 的操作，为了安全起见，一般还是建议使用 revert 命令，他也能实现和 reset 一样的效果，只不过区别来说，reset 是向后的，而 revert 是向前的，怎么理解呢？简单来说，把这个过程当做一次时光穿梭，reset 表示你犯了一个错，他会带你回到没有犯错之前，而 revert 会给你一个弥补方案，采用这个方案之后让你得到的结果和没犯错之前一样。

举个栗子：假设你改了 README 的描述，新增了一行文字，提交上去了，过一会你觉得这个写了有问题，想要撤销一下，但是又不想之前那个提交消失在当前历史当中，那么你就可以选择使用 git revert [commitId]，那么它就会产生一次新的提交，提交的内容就是帮你删掉你上面新增的内容，相当于是一个互补的操作。

git cherry-pick

其实对于我们工作中大部分场景下应该用不到这个功能，但是呢有的时候这个命令又能挽救你于水火之间，那就是当某个倒霉蛋忘记切分支，然后在 master 分支上改了代码，并且提交到了本地仓库中，这个时候使用git cherry-pick简直就是神器了。

git cherry-pick：将执行分支的指定提交合并到当前分支。

一听介绍就来精神了，雀氏有点东西，比如我在 master 分支提交了某个需求的代码，同时还没提交到远程分支，那么你就可以先 git log 查看一下当前的提交，找到 master 分支正常提交之后的所有 commitId，然后复制出来，然后再切到你建好的开发分支，接着执行 git cherry-pick master commitId1 commitId2 commitId4。

完事之后记得清理一下作案现场，把你的 master 分支代码恢复到正常的提交上去。