git分支管理

1、创建与合并分支

1. 开始的时候，mmaster分支是一条线，git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
   
2. 当创建新的分支，例如dev时，git新建了一个指针dev指向master相同的提交，再将HEAD指向dev，表示当前分支在dev上
   
   git创建一个分支很快，因为除了增加一个dev指针，改HEAD指向，工作区文件都没有任何改变。
3. 从现在开始对工作区的修改和提交就是针对dev分支了，比如提交一次后，dev往前移动一步，而master指针不变：
   
4. 假如在dev分支上的工作完成了，可以把dev合并到master上。最简单的合并方法就是直接把master指向dev的当前提交，就完成了合并：
   
   git合并分支也是很快的，就需要改指针，工作区内容不变
5. 合并完分支后，可以删除dev分支。删除dev分支就是把dev分支指针删除，这样就只剩下了一条master分支
   
   Fast-forward信息是告诉我们这次合并时”快进模式“，就是直接把master指向dev的当前提交，因此合并速度很快。

小结

查看命令：git branch
创建分支：git branch < name>
切换分支：git checkout < name>
创建+切换分支：git checkout -b < name>
合并某分支到当前分支：git merge < name>
删除分支：git branch -d < name>

2、解决冲突

合并分支往往不是一帆风顺的。。。

1. 创建一个新的分支
   
2. 修改code.txt 内容，并进行提交
   
3. 切换回master分支

	git checkout master

4. 在master的code.txt添加一行内容进行提交和第二步的命令是相同的

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

在这种情况下，git无法执行”快速合并“，只能试图把各自的修改合并起来，但是可能会发生冲突。

5. 执行如下命令尝试将dev分支合并到master分支上
   
   git告诉我们code.txt文件存在冲突，必须手动解决冲突之后再提交
6. 查看code.txt内容
   
7. git使用<<<<<<<,=======,>>>>>>>标记出不同分支的内容，修改后保存
8. 再次进行提交
9. 现在master分支和dev分支就变成了如下所示：
   
10. 用带参数的git log可以看到分支合并情况
    
11. 完成之后可以删除分支
    

3、分支管理策略

通常合并分支时候，如果可能git会使用fast forward模式，但是有些快速合并不能成功而且合并时候也没有冲突，这个时候会合并之后并做一次新的提交。。。
但是这种模式，删除分支后，会丢掉分支信息。
(1)、创建切换到dev分支

	git checkout -b dev

(2)、新建一个文件code2.txt编辑内容，并commit

	vim code2.txt
	git add code2.txt
	git commit -m 'dev提交code2.txt'

(3)、切换回master分支，编辑code.txt并进行一个提交
(4)、合并dev分支内容到master分支

		git merge dev

(5)、出现下面的提示时，是因为这次不能进行快速合并，所以git提示输入合并说明信息，输入之后合并内容之后git会自动创建一次新的提交:

将Merge branch ‘dev’改成我们想要的版本信息即可，效果如下：

(6)、使用分支命令查看分支信息

(7)、删除分支

如果想要强制禁用fast forward模式。git会在merge时生成一个新的commit，这样从分支历史上就可以看出分支信息。。
(1)、创建分支dev
(2)、修改code.txt内容，并提交
(3)、切换回master
(4)、准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward：

本次合并要创建一个新的commit，所以要加上-m参数，把commit描述写进去
(5)、合并之后，用git log查看分支历史，可以看到不使用Fast forward模式，merge后像这样：

4、Bug分支

软件开发中，bug是经常见的。出现了bug之后要修复，在git中，由于分支很强大，所以每个bug需要可以通过一个新的临时分支来修复，修复后合并分支然后将临时分支删除。。

(1)、当接到一个修复bug任务时，自然你想创建一个分支来修复它，但是在你当前的分支上还有工作没提交：

不是你想提交而是工作只进行到一半，没办法提交，预计还需要很长时间。但是必须在短时间内将bug修复，这个时候该怎么办呢？？？？

(2)、git提供了一个stash功能，可以把当前工作现场”储藏“起来，等以后恢复现场之后继续工作：

(3)、首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

(4)、现在来修复bug，将最后一行删除，修复之后再提交

(5)、修复完成后，切换到master分支完成合并，最后删除bug-01分支

(6)、现在bug-01修复完成，要回到dev分支继续干活！

(7)、工作区是干净的，刚才的现场存到哪了？？？使用git stash list命令查看：

工作现场还是存在的，git把stash内容存在某个地方了，需要回复一下。

小结

修复bug时候，会通过创建新的bug分支来进行修复，然后进行合并，最后删除该分支：当手上工作没有完成时，先把工作现场git stash一下， 然后去修复bug，修复后，再git stash pop回到工作现场。。。

总结

最后对本文提到过的一些git的操作命令做一个简单的总结：

查看分支：git branch
创建分支：git branch 分支名字
切换分支：git checkout 分支名字
创建并切换：git checkout -b 分支名字
合并分支：git merge 分支名字
删除分支：git branch -d 分支名字
分支冲突：两个分支都有了新的提交记录并且修改的是同一个文件
分支管理策略：

• 合并的时候，如果可以，执行快速合并
• –no-ff 禁止快速合并

Bug分支：

• 切换到bug所在分支，创建并切换到一个临时分支修复bug
• 修复完bug之后，切换回bug所在分支合并临时分支的内容，合并使用–no-ff模式
• 删除临时分支
• 切换回工作分支
• git stash pop 恢复工作现场