git之rebase和merge学习记录

git之rebase和merge学习记录

用git合代码遇到冲突,现在把解决过程中学习的记录下来.

现在有两个分支:一个是用来发版的master,另一个分支work,是从master切出来的用作自己写代码什么的.假设分支提交情况如下:



现在自己工作完了,要把work的代码合到master上面,一般就是用merge或者rebase.

先说下merge, 它不改变两个分支原来的提交记录,而是把要合并的分支的commit和自己本身的commit合并到一个补丁里面,然后加到两个提交记录后面产生一个新的记.比如你这样:

git checkout master; # 切换到master分支

git merge merge work; # 合并本地work分支

那么提交log就变成了：



merge可以留着C和D(互不相连的),可以把master分支切换到C或D.另一个记录的代码就不会影响在master上.

再说说rebase, 它是把当前分支的提交记录拿出来产生临时的补丁,再追加到要合并的分支上,提交记录就变成一条线:

git checkout work;# 切换到work分支, 要是出现代码冲突就在本分支解决

git rebase master;# 合并本地的master分支：



详细一点就是,在work分支上合并master的代码:

第一步把work的提交记录D拿出来(变成了补丁);

第二步把master分支拿过来(A <– B <– C);

第三步把work的D记录追加到master后面(A <– B <– C <– D).

到这里work分支的与master分支就合完了.

注意现在还是在work分支哦. master分支的还是A <– B <– C;要让master分支变成A <– B <– C <–D. 还要进行一次rebase

git checkout master; //切换到master分支, 以work为基准

git rebase work; //把刚才做过rebase的本地work分支(A <– B <– C <–D)做合并。

因为master与此时的work合并时,master没有新提交的记录了,第一步和第三步都没有产生影响, 所以master就变成了work分支的A <– B <– C <–D：



rebase可以把合并提交记录变成一个直线,适合代码实际发版使用.

注意：

在自己的分支合并master之前，先切换到master 更新它 然后再在自己分支合并。

重复说一下简单步骤(这里自己的分支名为zyl)：

先切到master分支 ：git pull 更新master到最新

然后切换分支 : git checkout zyl

在自己分支上合并master ：git rebase master

再切换到master ：git checkout master

在合并分支 ： git rebase zyl 再查看代码是否有改动

最后push master代码。