看完不会Git命令行我跪搓板(8)

场景分析和解决办法
一个文件，两个分支，每个分支都对文件中的相同一句话做了不同的修改。当一个分支修改完提交后，另外一个分支修改提交，然后合并另外一个分支的时候就会产生冲突，而解决的方法就是继续修改文件，把两个分支都操作的那句话进行最终编辑，然后提交即可。 [转载出处：www.11jj.com]

创建并切换到dev分支
$git checkout -b dev
M   TestGit.md
Switched to a new branch "dev"
编辑TestGit.md文件
$vim TestGit.md
编辑以后：
Hello World
Hello Chuizi
Hello XIAOMI
暂存
$git add TestGit.md
 提交
$git commit TestGit.md -m "dev commit file"
[dev 6a31928] dev commit file
 1 file changed, 1 insertion(+)
切换到master分支
$git checkout master
Switched to branch "master"
Your branch is up-to-date with "origin/master".
编辑TestGit.md文件
$vim TestGit.md
编辑以后：
Hello World
Hello Chuizi
Hello HUAWEI
暂存
$git add TestGit.md 

提交
$git commit TestGit.md -m "master commit file"
[master b62ed88] master commit file
 1 file changed, 1 insertion(+)
合并
$git merge dev
Auto-merging TestGit.md
CONFLICT (content): Merge conflict in TestGit.md
Automatic merge failed; fix conflicts and then commit the result.
编辑TestGit.md文件
$vim TestGit.md
Hello World
Hello Chuizi
<<<<<<< HEAD
Hello HUAWEI
=======
Hello XIAOMI
>>>>>>> dev

说明：=======上面是HEAD（master)版本 >>>>>>>上面是dev版本

解决冲突--进行编辑：
Hello World
Hello Chuizi
Hello HUAWEI
Hello XIAOMI
暂存
$git add TestGit.md 
提交
$git commit TestGit.md 
fatal: cannot do a partial commit during a merge.

说明：出现冲突以后，修改文件解决冲突后，不能提交部分文件

上面的commit修改为提交所有文件即可
$git commit -m "merge files"
[master 39791ca] merge files

查看分支的合并图：

$git log --graph --pretty=oneline --abbrev-commit
*   39791ca merge files
|\  
| * 6a31928 dev commit file
* | b62ed88 master commit file
|/  
* 555af4a first commit

从合并图可以看出来是dev和master的合并：
① 555af4a first commit ：首次的提交
② 6a31928 dev commit file b62ed88 master commit file ：dev先提交master后提交
③ 39791ca merge files ：解决冲突后合并提交

变基

$git log --graph --pretty=oneline --abbrev-commit
*   39791ca merge files
|\  
| * 6a31928 dev commit file
* | b62ed88 master commit file
|/  
* 555af4a first commit

上面是分支冲突后的合并图log，你会发现非常混乱，两个commit一个merge，并不在一条直线上。而这仅仅是一次冲突的合并。合并越多，历史log越乱！一个项目的合并次数可能达到成百上千，如果历史合并log非常混乱，，会对阅读造成非常大的障碍，影响工作效率，那能否左边的图是一条直线而非菱形呢？答案是肯定的，当本地出现冲突的时候使用变基--rebase来替代合并--merge。

那为什么merge后会产生菱形历史？这就要从其实质说起 : dev 分支、master 分支、两者的共同祖先一起合并生成新的快照，我们称这种提交叫做“合并提交"，而合并提交并非只有一个父提交，这里有两个dev和master。所以合并历史图出现了菱形。

复现冲突场景：dev和master分别修改了同一个文件的相同地方，并且执行了暂存和提交，然后我们这里执行rebase操作：
$git checkout dev
Switched to branch "dev"
$git rebase master
First, rewinding head to replay your work on top of it...
Applying: dev commit
Using index info to reconstruct a base tree...
M   TestGit.md
Falling back to patching base and 3-way merge...
Auto-merging TestGit.md
CONFLICT (content): Merge conflict in TestGit.md
error: Failed to merge in the changes.
Patch failed at 0001 dev commit
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

说明：rebase失败，让先解决冲突，然后用 "git rebase --continue"

$vim TestGit.md
$git add TestGit.md
$git rebase --continue
Applying: dev commit
$git checkout master
Switched to branch "master"
Your branch is ahead of "origin/master" by 1 commit.
  (use "git push" to publish your local commits)
$git merge dev
Updating 6321248..ce50a7f
Fast-forward
 TestGit.md | 1 +
 1 file changed, 1 insertion(+)
$git log --graph --pretty=oneline --abbrev-commit
* ce50a7f dev commit
* 6321248 master commit
* 555af4a first commit

为什么变基可以实现一条线的历史提交效果呢？那我们也看看其原理：首先找到两个要整合的分支（你当前所在的分支和要整合到的分支）的共同祖先，然后取得当前所在分支的每次提交引入的更改（diff），并把这些更改保存为临时文件，这之后将当前分支重置为要整合到的分支，最后在该分支上依次引入之前保存的每个更改。说白了就是记录dev的更改并保存，然后把保存的更改依次引入master分支，这样相当于所有的更改都在master上。merge和rebase的结果相同，但是提交历史完全不同。

你说还不明白，还是没有看出区别！但是你仔细想想其实区别很大：变基实际上是抛弃了dev的已有的提交，随后创建了新的对应提交，内容相似，但是却是不同的提交。

欢迎长按下图 -> 识别图中..

或者 扫一扫 关注我的公众号