Git 分支处理心得

一直以来用 git 都只有add commit push pull，今天闲下来研究了下分支冲突解决操作，顺便记录一手。

先说一下引子，今天研究这个的缘由是想到了，当我 fork 了别人的仓库后，以后时间里怎么一直保持同步更新，一顿百度猛如虎，得到了这么一个答案： https://blog.csdn.net/jsjsjs1789/article/details/86722086  博主已经讲的非常清楚了，概括起来就是再加一个 upstream 的 remote 仓库，然后以后 pull （fetch）的时候，从这个上游仓库拉下来（到一个新的上游分支），然后再合并到本地就好了，更新github就push到自己的仓库。同时还学到了一个小技巧，用 rebase 代替 merge 可以使得 commit 的 log 不那么冗余难看（针对以后PR的时候）。

关于 merge 和 rebase 的区别，通过实验之后发现：

merge 操作后 log 里面，一是加上了另一分支的更新 log，二是加上了一个 merge 的 log （也就是当前最新进度为 merge 操作）。

rebase 操作后 log 里面，同样是加上了另一分支的更新 log，重点是 rebase 前，本分支的最新 log 被置顶了（相当于就少了一个 log，并且把我原来的进度设置为最新进度）

 

然后说回 conflict 处理。对于 merge 和 rebase 都会遇到 conflict ，二者一般的操作都是 git add <冲突文件> 然后按照向导rebase --continue / git commit 把受到冲突影响而暂停的合并操作继续进行就好了，然后再到本地改冲突（处理

++<<<<<<< HEAD
 +two.
++=======
+ one.
++>>>>>>> master

）即可，或者是 merge/rebase --abort 取消本次的合并。

不同的是一些不寻常的操作，对于 rebase 有 --skip，直接放弃我自己的更改，直接采用别人的更改；另一个是 restore --staged 暂时把冲突文件移除暂存区，“临时地”完成合并操作

但是还是要进一步处理临时移出的冲突

这是如果再 restore（将不在暂存区的文件撤销更改）就相当于 --skip 丢弃自己的更改了。选择 add 就和之前 add 没啥区别了。

 

最后就是切换历史版本 git reset 操作，根据 soft  mixed  hard，会对working tree和index和HEAD进行重置

reset 不加参数（mixed）：保留工作目录（源码），清空 stage 区（暂存区），commit和index都回退

reset --soft：保留工作目录，并把重置HEAD所带来的新的差异放进暂存区，只回退了commit的信息，不会恢复到index file一级，如果还要提交，直接commit即可

reset --hard：重置 stage 区和工作目录（源码和 log 都重置）