git使用理解

1. merge和rebase
   开始在公司多人协作开发了，少不了git。前几天在代码库里的代码学习，发现有了新的更新，直接pull下来，却产生了一堆冲突。一时竟忘了如何操作，于是复习了一波，顺便记录一下。主要是关于merge和rebase的理解。

• 首先上merge的示意图：

• first foward的merge方式示意图：

主要作用是如果合并没有冲突，直接把头指针移到最新，分支和master无缝合体。而–no-ff则会取消这种模式，保留分支的提交记录，等于合并后，分支还是分支，只是把所有改变一并提交给了master。
拉取的时候也能比较直观的看出差别：

• 冲突：
  如何解决冲突：
  1、git status 查看冲突的文件，git diff 查看冲突的位置
  2、解决冲突，然后用 git add 标记文件冲突已经解决
  3、git commit 提交，完成 merge 操作

其实我都是用tortoise git，UI完全可视化，而且中文，直观又方便，推荐。tortoise git合并失败后直接点贮藏日志，完了弹出比较的界面，重新编辑完了之后保存，解决冲突。

• rebase：
  
  同情况下merge：
  

rebase会把整个的提交流程变得很简洁。虽然在不同分支开发，合并后却不会有非常多的提交记录，而是按分支和时间顺序合并为了一条。

但是，如果你是一人开发，且只有本地仓库，那么直接 rebase 问题都不会太大。但是如果你是多人协作且有远程仓库，那么区别就巨大了。因为你合并完分支之后还需要 push 到远程仓库供别人使用，此时的分支和别人的分支不一样，就会造成混乱。

所以，正确的使用rebase的场景应该是，从远程仓库拉去到本地时，此时与本地分支合并时，采用rebase。而合并推到远端时，则使用merge。

在公共分支上严禁使用rebase其他分支，而在本地分支上拉取的时候则可以rebase远端的。
即rebase应该用于同步而不是用于合并。

另外，要记得开发时经常拉取同步一下本地代码，不然攒着开发完了一起拉取，可能会出一堆冲突。

2. reset和revert

附加的，关于重置（reset）和恢复(revert）：

• reset
  我们从 Git 的 reset 命令开始。确实，你应该能够认为它就是一个 “回滚” —— 它将你本地环境返回到之前的提交。这里的 “本地环境” 一词，我们指的是你的本地仓库、暂存区以及工作目录。
  如果我们想回滚到前一个提交会发生什么呢？很简单 —— 我们只需要移动分支指针即可。Git 提供了为我们做这个动作的 reset 命令。
  而reset也包含一下几个选项：hard 在仓库中去重置指向的提交，用提交的内容去填充工作目录，并重置暂存区；soft 仅重置仓库中的指针；而 mixed（默认值）将重置指针和暂存区。
  
• revert
  git revert 命令的实际结果类似于 reset，但它的方法不同。reset 命令（默认）是在链中向后移动分支的指针去“撤销”更改，revert 命令是在链中添加一个新的提交去“取消”更改。
  
• 总结

为什么要优先选择 revert 而不是 reset 操作？如果你已经将你的提交链推送到远程仓库（其它人可以已经拉取了你的代码并开始工作），一个 revert 操作是让他们去获得更改的非常友好的方式。这是因为 Git 工作流可以非常好地在分支的末端添加提交，但是当有人 reset 分支指针之后，一组提交将再也看不见了，这可能会是一个挑战。

当我们以这种方式使用 Git 工作时，我们的基本规则之一是：在你的本地仓库中使用这种方式去更改还没有推送的代码是可以的。如果提交已经推送到了远程仓库，并且可能其它人已经使用它来工作了，那么应该避免这些重写提交历史的更改。

总之，如果你想回滚、撤销或者重写其它人已经在使用的一个提交链的历史，当你的同事试图将他们的更改合并到他们拉取的原始链上时，他们可能需要做更多的工作。如果你必须对已经推送并被其他人正在使用的代码做更改，在你做更改之前必须要与他们沟通，让他们先合并他们的更改。然后在这个侵入操作没有需要合并的内容之后，他们再拉取最新的副本。

你可能注意到了，在我们做了 reset 操作之后，原始的提交链仍然在那个位置。我们移动了指针，然后 reset 代码回到前一个提交，但它并没有删除任何提交。换句话说就是，只要我们知道我们所指向的原始提交，我们能够通过简单的返回到分支的原始链的头部来“恢复”指针到前面的位置。

参考文献：https://zhuanlan.zhihu.com/p/34197548