从零开始的Git详解（六）

分支管理

概念：分支好比两条互不干扰的时间线，合并相当于两条时间线重叠了。
场景：在自己的分支干活，不影响其他分支。~~自己代码写的咋样没点B数吗。~~

创建与合并分支

在Git里，有一个主分支被叫做master，有一个指针被叫做HEAD。

一开始，只有master这一条分支，HEAD指向当前分支即master，master指向提交。
使用命令git branch查看当前分支
创建新分支dev，和master一样指向提交，再把HEAD指向dev就代表切换到dev分支了。
使用命令git branch dev创建dev分支
使用命令git checkout dev或git switch dev切换到dev分支
dev分支新提交一次后，dev指针向前移动一步，而master指针不变，可以通过把master指向dev的当前提交来完成分支的合并。
在dev分支修改并提交readme.md文件
切换回master分支，无法查看到在dev分支添加的内容，因为那个提交是在dev分支的，master分支的提交点并没有改变。
使用命令git merge dev将dev分支合并到master分支上
合并分支以后，可以删除dev分支，即将dev指针给删除掉。
使用命令git branch -d dev删除dev分支

解决冲突
常见场景：
在某个分支节点对文件a的内容进行修改并commit，在master节点对文件a的内容做了不一样的修改并commit，此时执行git merge会报错，git只能试图将各自修改的内容合并起来，如果修改的是同一个内容就会产生冲突。
解决方案：
当git无法自动合并分支时，就必须手动编辑合并失败的文件，将其改为我们希望的内容，再提交，合并才能完成。
创建并切换到测试分支test，修改readme.md的内容并提交。

切换回master分支，修改readme.md的内容并提交。
此时git的各分支都有了各自的新的提交。
执行git merge报错，无法快速合并，在多个分支对readme.md做了修改并提交了。
使用vim命令，手动将冲突的地方修改成我们希望的内容。
解决冲突后，再次提交。
使用命令git log --graph可以产看到分支的合并图。

分支管理策略
常见场景：
Git默认使用Fast forward模式，在这种模式下，合并分支，并删除分支后，会丢失分支的信息，导致合并后的历史没有分支，看不出曾经合并过。
解决方案：
在合并分支的时候强制禁用Fast forward模式，添加--no-ff参数。

在实际开发中，master分支应该是非常稳定的，仅用来发布新版本，平时都在dev分支上干活，到了上线的时候，再把dev分支合并到master分支。
团队成员之间，每个人都有自己的分支，时不时地往dev分支合并你自己的分支即可。
所以，实际上团队合作的分支看起来就像下面这样：
创建并切换至mx分支。
新建一个mx.txt文件，并提交。
切换回master分支，强制禁用Fast forward模式合并mx分支。
查看分支合并历史。

临时分支(bug分支)
常见场景：
在软件开发的流程中，发现一个bug急需修复，这个时候可以直接创建一个新的临时分支来修复bug，修复后，合并分支，再删除临时分支。但是你当前分支的工作只做到一半，还不能直接commit到版本库，至少还要2小时，上司又要求你这个bug必须30分钟内解决。
解决方案：
可以通过git stash命令将当前的工作现场保存起来，等bug修复以后再恢复工作现场，接着干活。
修改FirstTest.txt文件，模拟当前工作现场，并保存工作现场
确定是在哪个分支修复bug，假设在master分支上修复，就从master分支创建临时分支bugfix-22。
切换回master分支，合并临时分支，再删除临时分支。
切换回mx分支，使用git stash applay命令来恢复现场，接着干活。

注：
master分支bug已经修复了，但是早期从master分支分出来的dev分支其实存在这个bug，那我是不是要再重新再dev分支修复一遍呢？
我们可以使用git cherry-pick <commmit id>命令，将指定提交所做的修改复制到dev分支。

feature分支

常见场景：
单独创建一个新功能的分支来开发新功能，开发完成以后，合并，删除，一气呵成。but，你开发到一半，客户说这个功能不要了，虽然白干了，但是对应的分支还是要销毁。but，Git这个时候会提示你该分支还未被合并，无法直接删除。
解决方案：
使用git branch -D <branch name>命令，强行删除。

创建一个新分支feature-music，模拟完成开发。
强制删除feature分支。

多人协作

概念：远程仓库默认名称为origin，从远程仓库克隆时，Git自动把本地的master分支和远程的master分支对应起来了。推送分支就是把该分支上所有本地提交都推送到远程仓库，但是并不是一定要把本地分支都推送到远程仓库，一般情况下：

master分支是主分支，要保证时刻与远程同步
dev分支是开发分支，团队成员都在上面工作，也需要与远程保持同步
bug分支只用于本地修复bug，一般不会推送到远程
feature分支是否推送到远程，取决于是否和其他成员联合开发

首先，查看当前关联的远程库信息，使用命令git remote -v
使用git push origin branch-name推送自己的修改，如果推送失败，则表示远程分支比本地更新，需要先用git pull试图合并。如果git push提示no tracking information表示本地分支与远程分支之间没有建立链接关系，使用命令git branch --set-upstream-to <branch-name> origin/<branch-name>建立链接。继续使用git pull，如果有冲突，则解决冲突后再推送。