廖雪峰Git教程学习笔记之分支管理

-------------------------------------------廖雪峰Git教程学习笔记----------------------------------------

分支管理

分支管理

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！

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

现在有了分支，就不用怕了。

你创建了一个属于你自己的分支，
别人看不到，还继续在原来的分支上正常工作，
而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，

这样，既安全，又不影响别人工作。

其他版本控制系统如SVN等都有分支管理，但这些版本控制系统创建和切换分支比蜗牛还慢，但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

底下评论：

(廖雪峰):git的分支最终是要合并到主干的

创建与合并分支

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

一开始的时候，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分支：

小结：
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。：

查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>或者git switch <name>
我们注意到切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支
创建+切换分支：git checkout -b <name>或者git switch -c <name>
合并某分支到当前分支：git merge <name>
删除分支：合并完成后，就可以放心地删除dev分支了,git branch -d <name>
注：当我们在本地仓库commit main分支时，用git status命令时，提示我们git push于这个本地仓库关联的远程仓库。

底下评论：

新分支和老分支的stage缓存区是共用的吗？我新建了一个dev分支，发现master分支中缓存区的文件在dev中依然可见。提交dev分区的缓存区后，master分支的缓存区也不见了。缓存区是不是只有一个，如果我在dev下面工作，添加到缓存区但是没有提交，切换到master之后，又修改了master分支的文件，同样添加到缓存区了，这样是不是容易混乱？
(廖雪峰回答):一般都是提交后切分支，你这种操作还很少见，建议切回去先把该提交的提交后再切分支.
在dev分支上修改了文件，但是并没有执行git add. git commit命令，然后切换到master分支，仍然能看到dev分支的改动，请问这个现象怎么解释？
的确，如果在在dev分区修改了文件，然后切换到主分区，查看status，是可以看到状态的，就可以在主分区来add 和commit dev分区的改动,但是如果在dev分区修改了文件，并且add 和commit 了那么切换到主分区就看不到修改了,你在dev分支修改了文件，但是你没有提交到仓库，实际上就是相当于你在本地手动修改了这个文件，仓库并不能保存你做的改动，所以在master分支能看到文件被改动了（相当于你没用dev分支直接修改了这个文件一样），所以你可以用master分支add、commit.
git切换分支时会把未add或未commit的内容带过去，这一点值得注意.为什么呢？因为未add的内容不属于任何一个分支，未commit的内容也不属于任何一个分支。也就是说，对于所有分支而言，工作区和暂存区是公共的.要想在分支间切换，又不想有上述影响，怎么办呢？git stash搞起。要注意，在当前分支git stash(藏匿)的内容，在其他分支也可以git stash pop出来，为什么？因为：工作区和暂存区是公共的。少说了一点，就是这两个分支是完全相同(即最后一次commit是完全相同)时，才可以在不add commit 新修改的情况下切换分支，但注意这个时候切换分支会把修改带到切换后的分支。例如你在b1分支修改文件，切换到b2，在b2上add commit，则这个commit是属于b2的，你commit之后在切换回b1，查看该文件，你会发现修改没了，切换回b2查看该文件，修改有了，再次证明最后在哪个分支commit，这个commit就属于那个分支的。如果两个分支完全不同，例：b1上新建一个分支b2，这个时候两个分支还是相同的，如果b1哪怕提交了一个commit，这两个分支就会变得完全不同了，两个完全不同的分支，如果你在b1上有修改，是没办法switch到b2的，会报错：【error: Your local changes to the following files would be overwritten by checkout:。。。】

解决冲突

合并分支往往也不是一帆风顺的。
现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

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

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

我们可以直接查看readme.txt的内容(这个应该是我们执行git merge由于冲突失败后git自动把这个文件变成了这个样子)：

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容。

我们修改如下后保存：

再提交：

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

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

最后，删除feature1分支：
$ git branch -d feature1
工作完成。

小结：

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
用git log --graph命令可以看到分支合并图。

底下评论：

廖老师，我有一个问题请教，当一个分支feature复制master分支后，并修改了一个文件（在该文件最后增加一行）然后提交，然后紧接着又在master分支对该文件进行修改（修改是在中间位置插入几行）然后提交，master提交后将dev进行合并，此时并没有报告冲突，而是直接将dev增加内容增加到该文件最后，并且master分支在改文件中间增加的几行也保留了，请问这是为什么？
(廖雪峰回答):这就叫没有冲突啊,一篇作文，你改开头，他改结尾，一合并，满分.你改开头，他也改开头，那叫冲突，因为不知道怎么合.
(廖雪峰)：git的master也是普通分支，合并并没有正向反向之分。
我有个疑问，主分支合并到其他分支跟其他分支合并到主分支，这两个过程一样吗？
(廖雪峰回答):习惯上把master叫主分支，你也完全可以把dev叫主分支,然后把master删了。从本质上说git分支都是个名字，没有主次之分.
-在master上解决完冲突，提交到版本库后，feature1和master的图中，feature1到master的最新commit间应该没有连线吧？个人理解，不知道对不对
- (廖雪峰回答):那个连线是master指的commit，它有两个前序节点,feature1的指针不一定会移到master指的commit，它可以自主独立发展.
- git checkout feature1你就懂啦那张图是相对主线master而言的，它的当前状态有两个，一个来自master,一个来自feature1，更确切的来说绿线应该往左。如果不删除feature1分支的话，这条分支倒是也可以继续往下走
- 绿线会使好多人会理解成feature1指针指向master merge之后的commit。建议廖老师在教程里面补充一下,切换到feature1分支并将master最后一次提交的内容 merge到feature1的操作，然后再删除feature1分支。因为直接切换到feature1之后，readme文件中的内容还是之前在feature1分支修改的内容，让很多人一头雾水，难以理解协作开发到底是如何merge的.

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

请注意--no-ff参数，表示禁用Fast forward,因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
可以看到，不使用Fast forward模式，merge后就像这样：

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

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

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

小结：
小结

Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

底下评论：

请问，git在本地创建自己的开发分支作用在于啥？跟直接在dev分支上进行开发有什么优势呢？
(廖雪峰回答):远程的dev分支在服务器上，除非你登录到服务器，否则开发不了。本地的dev分支在你机器上，直接可以操作，然后和服务器的dev同步。git分支的作用一是同步，二是合并。
如果采用ff模式的，则直接把master的指针直接指向了dev分支的最新提交，这样两个分支的最新提交的commit id就是一样的。如果采用 --no-ff 模式合并分支，由于不能直接把 master 指针直接指向 dev 分支的最新提交， master 分支只能进行一次提交操作，所以就会有内容一模一样，commit id 不同的问题。简单地说就是 -no-ff 模式进行了一次新的 git commit 操作。这也是为什么采用 -no-ff 模式要加入参数 -m 的原因。
不用--no-ff，实际上只是将master的指针update成dev分支而已，用的还是dev的commit ID，而使用之后，则是重新commit了一哈，有了新的commit ID.
dev理解为测试分支，测试成功之后，提交到master分支，时间线向前走了一个版本，并创建一个独立的id。如果不加no-ff(fast forward)则是master指针直接指向dev分支，这样造成的问题是不能很好的看到我们曾经是在dev的基础上merge的这个版本。
git有个最佳实践，master是主分支，用来做正式发布版之后的保留历史，其他分支包括dev用来做正常开发，多个feature用来做某些特性功能，release用来做发布版历史，每次发布都是用release打包，hotfix用来做发布版之后的一些及时迭代修复bug的工作。
在实际开发中，每个开发在公司远程仓库，都有一个对应每个人自己的远程分支，每次提交时教程里面讲git push 中master参数换成对应开发人员的分支就好了，比如devloper1，控制版本上线的人比如运维人员，在远程仓库的服务器上，再选择性地把某个开发人员的分支合并进真正的master实现上线.
你在远程可以建立dev分支然后开发人员把自己本地的dev分支和远程dev分支关联就好了，然后就可以往上推了。在github上你只要和远程库关联了，即使那没有dev分支，你自己建立一个dev分支，然后用git push origin dev就可以推送上去，同时远程会自动建立dev分支.

Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复.每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
小结：

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作，
工作现场存到哪去了？用git stash list命令看看：
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
- 一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
- 另一种方式是用git stash pop，恢复的同时把stash内容也删了
你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
你需要git stash命令保存现场，才能从dev分支切换到master分支。
在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。
为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么当然可以直接在dev分支上修复bug，然后在master分支上“重放”.

Feature分支

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

小结:

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

多人协作

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

或者，用git remote -v显示更详细的信息：

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

推送分支:
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

如果要推送其他分支，比如dev，就改成：

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

master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

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

抓取分支：
多人协作时，大家都会往master和dev分支上推送各自的修改。
当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：

注：如果要在GitHub上的远程仓库创建分支，可以这样操作：

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

你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：

推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，

先用git pull把最新的提交从origin/dev抓下来，
然后，在本地合并，解决冲突，再推送

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

简而言之，设置这个东西，是让你不用每次都git push origin dev , git pull origin dev。关联后可以简化为git pull , git push。
再pull：

这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：

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

首先，可以试图用git push origin <branch-name>推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to=origin/<branch-name> <branch-name>。

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

底下评论：

执行git checkout -b dev origin/dev后，本地dev分支就和远程dev分支关联了呀，例子中“小伙伴”这样做后不就可以push了吗，为什么例子中“我”就需要专门的关联分支，例子场景中，”我“不是用这个命令创建的dev分支？
(回答):因为之前的仓库，是用git switch -c dev 创建的dev分支，然后用git push origin dev push到远端的，并不是说建立了关联。如果你没执行git push origin dev时，只执行git push,git也会提示你让你关联。这时你执行git push --set-upstream origin dev，也就是说把本地分支与远端的dev分支关联在了一起。关联后，你再执行git push就没问题了。然后另外一个仓库操作了git checkout -b dev origin/dev以后，你再pull，也不会让你设置这个东西了。简而言之，设置这个东西，是让你不用每次都 git push origin dev , git pull origin dev。关联后可以简化为git pull , git push。
在本地克隆远程仓库git clone git@xxx.git,然后，在本地创建开发分支，并关联远程库分支git switch -c dev origin/dev,那么，在本地开发完后，是在开发分支上提交，推送吗？还是把分支切换到master分支上合并本地dev分支，然后在master分支推送？如果在本地开发分支dev上推送，推送完还要切换到本地master上合并，合并完后需要删除dev分支。再次开发时，还要重新创建本地开发分支git switch -c dev origin/dev？
(廖雪峰回答):你可以只使用一个master分支来实现本地/远程互相交换修改,也可以使用master/dev/release多个分支来实现本地master/远程master，本地dev/远程dev，本地release/远程relase之间交换修改,一切取决于项目管理的需要.
(廖雪峰):本地master分支和远程master分支同步，本地dev和远程dev同步，名字只是一个代号，切忌本地master同步远程dev这种，自己把自己绕进去。你在本地dev开发，和远程dev同步是你的责任，不然其他人没法拿到你的commit.是否要把本地dev合并到本地master，看你的策略，如果每个commit你都立刻合并到master然后和远程同步，那要两个分支就没意义了。正常开发是在某个大功能稳定时，由某个人把dev合并到master，同步远程master，最好打上v1.1，v1.2的标签，便于跟踪。

Rebase

多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。
每次合并再push后，分支变成了这样：

总之看上去很乱，有强迫症的童鞋会问：为什么Git的提交历史不能是一条干净的直线？其实是可以做到的！Git有一种称为rebase的操作。
我们还是从实际问题出发，看看怎么把分叉的提交变成直线。
在和远程分支同步后，我们对hello.py这个文件又做了两次提交。用git log命令看看：

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

很不幸，失败了，这说明有人先于我们推送了远程分支。按照经验，先pull一下：

再用git status看看状态：

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

对强迫症童鞋来说，现在事情有点不对头，提交历史分叉了。如果现在把本地分支push到远程，有没有问题？有！什么问题？不好看！有没有解决方法？有！这个时候，rebase就派上了用场。
我们输入命令git rebase试试：

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

原本分叉的提交现在变成一条直线了！这种神奇的操作是怎么实现的？其实原理非常简单。我们注意观察，发现Git把我们本地的提交“挪动”了位置，放到了f005ed4 (origin/master) set exit=1之后，这样，整个提交历史就成了一条直线。rebase操作前后，最终的提交内容是一致的，但是，我们本地的commit修改内容已经变化了，它们的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4内容是一致的。