git学习笔记3——分支

1.分支基础

分支：允许多人在不同的时间线上对同一个东西工作，且互不干扰，最后再把结果都合并到主分支master

工作原理：HEAD指向的是当前在哪个分支上，而分支指向的是当前工作分支的提交点

注意：未add的内容不属于任何一个分支， 未commit的内容也不属于任何一个分支。 因此对于所有分支而言，工作区和暂存区是公共的。

1.一开始只有master分支

2.创建开发分支dev

3.在dev分支上新提交一次后，dev指针往前移动一步，而master指针不变

4.在dev上的工作完成就可以把dev合并到master上。直接把master指向dev的当前提交，就完成了合并

5.合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉

分支操作语句

git branch				#查看分支：查看所有分支，当前分支会用*标出

git branch <name>		#创建分支

git checkout <name>		#切换分支：将HEAD指向分支

git checkout -b <name>	#创建+切换分支

git merge <name>		#合并某分支到当前分支：即把当前分支指向的提交更新到和分支一样

git merge --no-ff <name>	#--no-ff参数，表示禁用Fast forward合并方式，采用普通方式合并，合并后的历史有分支，能看出来曾经做过合并

git branch -d <name>	#删除分支,若该分支还未合并，则会删除失败
git branch -D <name>	#-D表示强行删除该分支，用于删除未合并但不需要了的分支

2.分支冲突

分支冲突：当多个不同分支分别对相同的文件做出修改时，而且都commit了，这个时候要合并分支就会出现冲突，git不知道选择哪个分支的内容

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

git log --graph	#查看分支合并图

3.分支管理策略

按照几个基本原则进行分支管理：

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

干活——每个人都在自己的分支上如michal和bob干活，时不时地往开发分支dev上汇总合并，即dev分支是不稳定的，需要发布的时候再把dev分支合并到master分支，然后在master上发布

注意：本地仓库一般设有主分支master和开发分支dev，远程仓库也设有主分支master和开发分支dev，推送到远程仓库分区是对应的

4.bug分支（新功能分支）

软件开发中，有了bug就需要修复，在Git中，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当前正在dev上的工作只进行到一半，还没法add和commit，但是，必须先修复该bug

Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等修复bug后回来恢复现场继续工作

步骤：

git stash	#将当前分支的工作区修改暂存起来，存起来后工作区就是干净的了，修改被转移到别的地方去了

2.确定要在哪个分支上修复bug，就从那个分支创建临时分支，如master分支

git checkout master			#切换到修复bug的分支
git checkout -b issue-101	#创建并切换到临时分支issue-101修复101号bug

3.修复完成后，切换回master分支，完成合并，最后删除临时分支issue-101

git checkout master		
git merge --no-ff -m "merged bug fix 101" issue-101		#将issue-101分支合并到master分支，普通合并模式，并用-m做出说明
git branch -d issue-101		#删除bug临时分支

4.回到dev分支干活

git checkout dev	
git stash list		#查看dev分支之前的工作现场存在哪里
git stash apply		#恢复工作现场，但是不删除工作现场的暂存
git stash pop		#恢复工作现场，并删除暂存

总结

先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场