git：rebase、merge

git：rebase 、merge

git merge--会有新的提交

在 Git 中合并两个分支时会产生一个特殊的提交记录，它有两个父节点。翻译成自然语言相当于：“我要把这两个父节点本身及它们所有的祖先都包含进来。”

# 在master分支上
git merge bugFix

# 会生成一个新的提交在master上面

# 在bugfix去mergemaster，因为之前master已经合并 了，所以直接快速合并
git checkout bugFix

git merge master

因为 master 继承自 bugFix，Git 什么都不用做，只是简单地把 bugFix 移动到 master 所指向的那个提交记录。

现在所有提交记录的颜色都一样了，这表明每一个分支都包含了代码库的所有修改

rebase--不会生成新的提交

不要在master使用，在自己的分支使用即可

merge更加关注历史记录

git rebase。Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。

Rebase 的优势就是可以创造更线性的提交历史。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。

还是准备了两个分支；注意当前所在的分支是 bugFix（星号标识的是当前分支）

我们想要把 bugFix 分支里的工作直接移到 master 分支上。移动以后会使得两个分支的功能看起来像是按顺序开发，但实际上它们是并行开发的。

git rebase master 

现在 bugFix 分支上的工作在 master 的最顶端，同时我们也得到了一个更线性的提交序列。

注意，提交记录 C3 依然存在（树上那个半透明的节点），而 C3' 是我们 Rebase 到 master 分支上的 C3 的副本。

现在唯一的问题就是 master 还没有更新，现在我们切换到了 master 上。把它 rebase 到 bugFix 分支上……

git rebase bugFix

由于 bugFix 继承自 master，所以 Git 只是简单的把 master 分支的引用向前移动了一下而已。

注意变基的时候是在变的分支上，往要变的分支上变。

在bugFix上往master变： git rebase master

往对方分支变基的时候，首先自己要在自己的分支上面，才可以往对方变

变完之后自己的分支上面就有了其他分支的东西，但是其他分支还在自己的位置，需要在其他分支上再次放这个分支变基两个分支的起点才是一致的。

多分支rebase

把这些分支 rebase 到 master 上。希望得到有序的提交历史，也就是我们最终的结果应该是 C6' 在 C7' 上面， C5' 在 C6' 上面，依此类推。

即使你搞砸了也没关系，用 reset 命令就可以重新开始了。

git rebase master bugFix
git rebase bugFix side
git rebase side another
git rebase another master

直接使用分支变基的时候会将分支的所有commit都复制过去，如果存在已经重复的commit，那么就只是移动分支指针没有 内容上的移动

重新建立基础

当前有两个分支，master和feature

master分支目前有4个提交，

feature分支处于第2个提交分支出去了，但是还没有任何人提交。

添加文件feature.txt，提交

修改master.txt文件内容，删除以及添加，在feature分支提交

再修改master.txt文件内容，删除以及添加，在feature分支提交

再修改feature.txt文件内容，添加，在feature分支提交

可以看到只是改变了feature的历史，没有改变master的历史

所有的commit一个个复制一遍插在base之上，

**<font style="color:#F5222D;">git rebase -i master </font>**当前所在分支交互式的rebase到master，

这里不编辑直接exit，可以看到下面的提示，其实此时feature init 提交已经加上去了，但是commit 1 发生了冲突

手动处理 conflict 1之后，按照上面的提示进行add 和commit ，再执行 git rebase --continue

这个时候其实conflict 1 可以加在master上面了，但是conflict 2 又有冲突了，手动解决之后，再执行git rebase --continue

此时没有冲突了，feature 1 直接就加上去了