大家好，我是讯享网，很高兴认识大家。

分支管理

git学习参考
廖雪峰官方网站
git基本操作，一篇文章就够了！

一、分支作用

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

二、分支的创建与合并

在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

1、分支含义及原理

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

讯享网

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

2、创建一个分支

首先，我们创建dev分支：

3、切换到指定分支上

切换到分支dev上：

4、创建并切换到创建的分支上

我们创建dev分支，然后切换到dev分支：
命令：git checkout -b 分支名
具体命令：git checkout -b dev

5、查看当前分支

命令：git branch

git branch命令会列出所有分支，当前分支前面会标一个*号。

6、在分支上修改提交

然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：“Creating a new branch is quick.”

7、从dev分支切换回主分支master

命令：git checkout master

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：

8、分支合并

现在，我们把dev分支的工作成果合并到master分支上：

命令： git merge 分支名
具体命令：git merge dev

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。

9、删除分支

合并完成后，就可以放心地删除dev分支了：

命令：git branch -d 分支名称
具体命令：git branch -d dev

删除后，查看branch，就只剩下master分支了：

10 、switch

我们注意到切换分支使用git checkout ，而前面讲过的撤销修改则是git checkout – ，同一个命令，有两种作用，确实有点令人迷惑。

实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：

1、用switch创建并切换到刚创建的分支

命令：git switch -c 分支名

创建并切换到新的dev分支，可以使用：
命令 git switch -c dev

1、用switch切换分支

直接切换到已有的master分支，可以使用：

命令：git switch master

使用新的git switch命令，比git checkout要更容易理解。

小结

Git鼓励大量使用分支：

查看分支：git branch

创建分支：git branch

切换分支：git checkout 或者git switch

创建+切换分支：git checkout -b 或者git switch -c

合并某分支到当前分支：git merge

删除分支：git branch -d

三、主分支和分支的矛盾

当我们创建了分支feature1 在分支feature1上修改文件并提交。在主master也修改了文件在提交时，此时master已经不再之前的位置上了，此时合并分支会出现错误。

准备新的feature1分支，继续我们的新分支开发：

修改readme.txt最后一行，改为：“Creating a new branch is quick AND simple.”
在feature1分支上提交：

切换到master分支：

Git还会自动提示我们当前master分支(执行切换分支命令时所在的分支)比远程的master分支要超前1个提交。

在master分支上把readme.txt文件的最后一行改为：“Creating a new branch is quick & simple.”

现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。

git status也可以告诉我们冲突的文件：

我们可以直接查看readme.txt的内容：

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

再提交：

现在，master分支和feature1分支变成了下图所示：

1、用带参数的git log也可以看到分支的合并情况：

命令：git log --graph --pretty=oneline --abbrev-commit

最后，删除feature1分支：

小结

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

用git log --graph命令可以看到分支合并图。

四、分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

下面我们实战一下 --no-ff 方式的git merge：

首先，仍然创建并切换dev分支：

修改readme.txt文件，并提交一个新的commit：

现在，我们切换回master：

准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward：
命令：git merge --no-ff -m “注释信息” 要合并的分支名

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

合并后，我们用git log看看分支历史：

可以看到，不使用Fast forward模式，merge后就像这样：

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

Git分支十分强大，在团队开发中应该充分应用。

本节主要是说明合并要使用非forward模式 以保留合并历史，合并关闭forward模式的命令为：
git merge --graph --no-ff -m “注释信息” 要合并的分支名
查看提交合并日志图命令：
git log --graph --pretty=oneline --abbrev-commit

五、处理Bug的分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：
下面就是工作的内容 正在再使用readme.txt 写代码writing code

现在查看一下分支dev工作空间的状态 我们正在修改readme.txt
并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
首先我们使用命令git stash将当前的分支dev临时存储到其他地方 如 stash@{i} i=1,2,3…n中
然后我们在出现Bug的分支上建立一个分支issus-101用于处理bug，处理完后将分支issus-101与出现bug分支合并，最后删除issus-101分支。最后回到之前工作的dev分支，从stash@{i} i=1,2,3…n中恢复我们之前的工作内容。最后清空stash@{i} i=1,2,3…n。

1、git stash 隐藏当前变更，以便能够切换分支

幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作： 隐藏当前分支变更 （存储到stash中去了，等处理好Bug回来再复原）
命令： git stash

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支issus-101：
切换分支到master分支：

创建处理bug的分支issus-101分支并进入issus-101分支

查看出现bug的文件内容

处理bug 并提交

修复完成后，切换到master分支，将分支issus-101合并到主分支master上
>

最后删除issue-101分支

太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！

工作区是干净的，刚才的工作现场存到哪去了？

用git stash list命令看看

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

1、用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

2、用git stash pop，恢复的同时把stash内容也删了：
恢复到之前的状态了
查看一下stash暂存区有没有东西，有的话给他清除掉用命令
git stash drop stash@{i} i=1,2,3…n

====================================================

1、“插叙”总结一下 git stash命令

（1）git stash save “save message” : 执行存储时，添加备注，方便查找，只有git stash 也是可以的，但查找时不方便识别。

（2）git stash list ：查看stash了哪些存储

（3）git stash show：显示做了哪些改动，默认show第一个存储,如果要显示其他存贮，后面加stash@{$num}，比如第二个 git stash show stash@{1}

（4）git stash show -p : 显示第一个存储的改动，如果想显示其他存存储，命令：git stash show stash@{$num} -p ，比如第二个：git stash show stash@{1} -p

（5）git stash apply :应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}，如果要使用其他个，git stash apply stash@{$num} ， 比如第二个：git stash apply stash@{1}

（6）git stash pop：命令恢复之前缓存的工作目录，将缓存堆栈中的对应stash删除，并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0}，如果要应用并删除其他stash，命令：git stash pop stash@{$num} ，比如应用并删除第二个：git stash pop stash@{1}

（7）git stash drop stash@{ KaTeX parse error: Expected 'EOF', got '}' at position 4: num}̲ ：丢弃stash@{ num}存储，从列表中删除这个存储

（8）git stash clear ：删除所有缓存的stash

====================================================

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。
下面是修复好的带有 bug的master的分支的bug文件readme.txt内容：
下面是修复好的带有 bug的master之前创建的dev分支的现在的bug文件readme.txt内容：
可见 dev分支上的bug并没有改过来

那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？
有木有更简单的方法？
有！

2、commit 重提交（将其他分支的提交在本分分支提交）

同样的bug，要在dev上修复，我们只需要把7970f09 fix bug over now commit 这个提交所做的修改“复制”到dev分支。注意：我们只想复制7970f09 fix bug over now commit 这个提交所做的修改，并不是把整个master分支merge过来。

如何查询 7970f09 fix bug over now commit 这个提交的commit id

下面是我们在isuss-101分支上的修改好bug后的提交，现在查询一下这次提交的commit id
命令 git reflog 查询提交记录 按q退出

为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支，并合并，在合并之前，要提交更改或隐藏更改：
命令：git cherry-pick commit id

Git自动给dev分支做了一次提交，注意这次提交的commit是4053bfe，它并不同于master的7970f09，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

git 在使用命令git cherry-pick commit id自动给dev分支做了一次提交，这次提交的commit id为4053bfe

当时修改bug时在分支issus-101上的提交 提交的commit id 为7970f09

有些聪明的童鞋会想了，既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？当然可以，不过你仍然需要git stash命令保存现场，才能从dev分支切换到master分支。

小结
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

六、feature分支（删除一个准备提交的分支，需要强行删除）

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。

于是准备开发：
创建分支feature-vulcan 并在分支上开发项目
5分钟后，开发完毕，提交：
切回自己工作的分支dev分支，准备合并分支feature-vulcan：

一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。 但是！ 就在此时，接到上级命令，因经费不足，新功能必须取消！
虽然白干了，但是这个包含机密资料的分支还是必须就地销毁：
销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。

现在我们强行删除： 删除一个已经提交更改的分支—强项删除分支： 命令：git branch -D 分支名

终于删除成功！

小结
开发一个新feature，最好新建一个分支；
如果要丢弃一个没有被合并过的分支，可以通过git branch -D 强行删除。

七、多人协作

1、获取远程信息

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

要查看远程库的信息，用
命令：git remote：

或者，用git remote -v显示更详细的信息：
命令：git remote -v
上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

2、推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
命令： git push origin 要推送的分支名
如 git push origin master 推送分支master
如git push origin dev
该命令可以在任何分支下执行
推送master分支：git push origin master

推送dev分支：git push origin dev

注意： origin代表的是默认的远程仓库，这个仓库是你之前用命令关联的远程库
命令：git remote add origin :GitHub账号/远程仓库名.git
命令：git remote add origin :kevinyang330/LearnGit.git
即上次我们关联的远程库是LearnGit，因此我们本次推送到的也是这个远程库。此时origin代表的是默认的远程仓库是LearnGit

下面是推送后的远程仓库

1、那些分支需要推送

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

master分支是主分支，因此要时刻与远程同步；

dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

3、抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆：

1、创建模拟伙伴 名字为Alice，模型项目开发

3、创建用户配置 用户名为Alice

4、连接远程仓库，查看远程

5、克隆远程项目

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：

现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：
git checkout -b dev origin/dev

如果执行命令失败，就先执行命令 git pull
此时Alice和我们共用一个远程的分支dev

git checkout -b dev origin/dev 意思是说.创建并切换到dev分支上,接着跟远程的origin地址上的dev分支关联起来,这里要注意origin代表是一个路径,可以用git remote -v 查看
说来白了,origin/dev有点像是:xxxxx/yyyyy.git/dev 接着在dev当前分支下进行操作,add,commit后,用git push origin dev,意思是推送当前的dev分支到远程origin地址的dev分支上

Alice修改本地分支dev并推送到远程

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：

修改后的内容为：

现在Alice，对文件env.txt
进行了修改并向origin/dev分支推送了他的提交,推送到了远程。而碰巧你也对同样的文件(env.txt )也作了修改，并试图推送：
修改后的内容为：


推送失败

推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送

git pull 把最新的提交从origin/dev抓下来并合并

合并后的内容为：

手动解决冲突，将env.txt的内容修改为：

添加 提交 推送更改：
提交成功

因此，多人协作的工作模式通常是这样：

1、首先，可以试图用git push origin 推送自己的修改；

2、 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

3、如果合并有冲突，则解决冲突，并在本地提交；

4、没有冲突或者解决掉冲突后，再用git push origin 推送就能成功！

这就是多人协作的工作模式，一旦熟悉了，就非常简单

小结

查看远程库信息，使用git remote -v； 本地新建的分支如果不推送到远程，对其他人就是不可见的； 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交； 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致； 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name； 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。 

讯享网

八、Rebase

在上一节我们看到了，多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。

每次合并再push后，分支变成了这样：

讯享网$ git log --graph --pretty=oneline --abbrev-commit * d1be385 (HEAD -> master, origin/master) init hello * e5e69f1 Merge branch 'dev' |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env | |/ * | 12a631b merged bug fix 101 |\ \ | * | 4c805e2 fix bug 101 |/ / * | e1e9c68 merge with no-ff |\ \ | |/ | * f52c633 add merge |/ * cf810e4 conflict fixed 

总之看上去很乱，有强迫症的童鞋会问：为什么Git的提交历史不能是一条干净的直线？

其实是可以做到的！

Git有一种称为rebase的操作，有人把它翻译成“变基”。

先不要随意展开想象。我们还是从实际问题出发，看看怎么把分叉的提交变成直线。

在和远程分支同步后，我们对hello.py这个文件做了两次提交。用git log命令看看：

$ git log --graph --pretty=oneline --abbrev-commit * 582d922 (HEAD -> master) add author *  add comment * d1be385 (origin/master) init hello * e5e69f1 Merge branch 'dev' |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env 

…

注意到Git用 (HEAD ->master) 和 (origin/master) 标识出当前分支的HEAD和远程origin的位置分别是582d922 add author和d1be385 init hello，本地分支比远程分支快两个提交。

现在我们尝试推送本地分支（目前我们处在582d922 (HEAD -> master) add author处，远程的master处在d1be385 (origin/master) init hello）：

讯享网$ git push origin master To github.com:michaelliao/learngit.git ! [rejected] master -> master (fetch first) error: failed to push some refs to ':michaelliao/learngit.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 

很不幸，失败了，这说明有人先于我们推送了远程分支。按照经验，先pull一下（下拉并合并别人的推送中的更改）：

$ git pull remote: Counting objects: 3, done. remote: Compressing objects: 100% (1/1), done. remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0 Unpacking objects: 100% (3/3), done. From github.com:michaelliao/learngit d1be385..f005ed4 master -> origin/master * [new tag] v1.0 -> v1.0 Auto-merging hello.py Merge made by the 'recursive' strategy. hello.py | 1 + 1 file changed, 1 insertion(+) 

再用git status看看状态：

讯享网$ git status On branch master Your branch is ahead of 'origin/master' by 3 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean 

加上刚才合并的提交，现在我们本地分支比远程分支超前3个提交。

用git log看看：

$ git log --graph --pretty=oneline --abbrev-commit * e0ea545 (HEAD -> master) Merge branch 'master' of github.com:michaelliao/learngit（自己在master上的远程提交推送（下拉合并了别人的更改）） |\ | * f005ed4 (origin/master) set exit=1（自己在master上的提交） * | 582d922 add author（别人在master上的远程提交推送） * |  add comment（别人在master上的远程提交推送） |/ * d1be385 init hello 远程master分支所处位置 ... 

对强迫症童鞋来说，现在事情有点不对头，提交历史分叉了。如果现在把本地分支push到远程，有没有问题？

有！

什么问题？

不好看！

有没有解决方法？

有！

这个时候，rebase就派上了用场。我们输入命令git rebase试试：

讯享网$ git rebase First, rewinding head to replay your work on top of it... Applying: add comment Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py Applying: add author Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py 

输出了一大堆操作，到底是啥效果？再用git log看看：

$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master) add author * 3611cfe add comment * f005ed4 (origin/master) set exit=1 （自己在master上的提交） * d1be385 init hello 远程master分支所处位置 ... 

这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。

最后，通过push操作把本地分支推送到远程：

讯享网Mac:~/learngit michael$ git push origin master Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done. Total 6 (delta 2), reused 0 (delta 0) remote: Resolving deltas: 100% (2/2), completed with 1 local object. To github.com:michaelliao/learngit.git f005ed4..7e61ed4 master -> master 

再用git log看看效果：

$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master, origin/master) add author * 3611cfe add comment * f005ed4 set exit=1 * d1be385 init hello ... 

远程分支的提交历史也是一条直线。

小结
rebase操作可以把本地未push的分叉提交历史整理成直线；
大白话理解就是，将多个人在同一个分支上的提交收集起来，再由一个人（git模拟的人）依次的提交次序。这样就不会产生提交分支。
rebase的目的是使得我们在查看历史提交的变化时更容易，
因为分叉的提交需要三方对比。