用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可以把合并提交记录变成一个直线,适合代码实际发版使用.
就这些吧, 写的比较浅显.