为什么要创建分支：在实际的项目开发过程之中,利用分支可以在保证已有项目完整性的前提下实现项目的更新与维护的操作,这一点是使用版本控制工具最为重要的因素,但是SVN本身也有分支管理,只不过它的分支支持与GIT分支支持相比功能稍显薄弱。
1.分支基本操作：所有的项目在进行编写的时候一定要创建一个新的分支,而将 master分支保留给完整版本,既然需要进行分支的操作,所以首先需要进行分支创建,随后还需要实现分支的合并处理。
● 【master分支】首先查看当前项目之中已有的分支：所有的git仓库都会默认的创建一个master分支，在没有任何配置的情况下使用的就是master分支
● 【master分支】查看当前分支下的所有分支：git branch
● 【master分支】创建一个dev子分支：git branch dev
● 【master分支】创建完成了新分支，但是如果未切换当前还在master分支上，现在可以再次查询所有分支看下当前在哪个分支上：git branch 前面带*并且颜色为绿色的分支就表示当前分支
● 【master分支】切换当前分支为dev分支：git checkout dev 切换dev分支下后，dev分支下的所有修改不会影响到master分支上的所有代码。
● 【dev分支】在dev分支里面进行一个正常的代码编写
● 建立Dept.java文件，并编写代码
● 将代码进行提交：
● git add .
● git commit -m "Add Dept.java File"
● 【dev分支】为了方便的观察到两个分支不会相互影响，可以将分支切换回master分支上观察：git checkout master
● 【master分支】在master分支上合并dev分支：git merge dev
● 【master分支】对于当前的分支本质上都是在当前本地仓库提供的存储,而远程的GITHUB并没有此分支的信息,
所以需要考虑将此分支传输到 github上：git push -u origin dev
●【 master分支】如果说现在项目已经开发完成了,那么应该考虑进行分支的删除操作,既然要进行分支的删除,则可以使用如下的指令完成,但是千万要记住,本分支无法删除自己的分支信息。
●在master分支上删除dev分支：git branch -d dev
● 在进行分支删除的时候并不是所有的分支都可以被删除,例如,某些分支上正在执行着一些代码的开发操作,突然发现这样的分支进行的项目维护没有任何的意义,那么就有可能在没有被提交修改之前进行该分支的删除。
●【master分支】创建并切换到dev分支上：git checkout -b dev 相当于先执行分支创建，而后再执行分支的切换
●【dev分支】 分支操作：创建一个test.txt文件
●【dev分支】内容提交暂存库：git add .
●【dev分支】内容提交到版本库：git commit -m "test.txt"
●【dev分支】切换回master分支：git checkout master
●【master分支】删除掉dev分支：git branch -D dev
对于当前的dev分支发现合并是没有任何意义的,但是对于当前已经提交的代码如果彻底不要,则必须修改参数,此时才可以彻底删除掉未提交(未提交到远程仓库的分支)的分支。
2.分支合并冲突：
● 【master分支】在master分支上创建并切换到dev分支：git checkout -b dev
●【dev分支】在dev分支上创建并切换到debug分支：git checkout -b debug
●【debug分支】在 debug分支上经过开发人员的梳理发现了程序代码的问题,于是修改了 Emp.java类的代码，然后将代码提交到版本库：git commit -a -m "Modify Emp.java bug"
●【debug分支】在 debug分支修改的同时,dev分支也在忙碌着修改代码,现在切换回到dev分支上：git checkout dev
●【dev分支】在dev分支上也修改了Emp.java文件，同时也将其提交到了版本库里面：git commit -a -m "Modify Emp.java bug by dev" 那么此时dev分支也正常提交,但是此时与 debug属于两个不同的分支,两个彼此独立。
●【dev分支】将debug分支重新合并到dev分支上：git merge debug 这个时候会发现此时的代码里面出现了冲突,因为两个分支都修改了 Emp. java程序类,那么这个时候将无法进行合并,于是这时候会在冲突产生的文件上进行标注。
●【dev分支】由于合并机制是通过dev分支开启的,所以应该在dev分支里面修复相应的冲突文件,手工修改 Emp.java文件
●【dev分支】冲突修改完毕之后重新再一次进行仓库的提交：git commit -a -m "Resolve conflict in Emp.java"
●【dev分支】现在冲突解决了，随后就可以删除掉debug分支：git branch -d debug
●【dev分支】现在阶段性的开发完成，将dev分支发送到远程的github上：git push -u origin dev
●【dev分支】既然现在开发完成了，切换到master分支上：git checkout master
●【master分支】在master分支上进行分支的合并处理：git merge dev
●【master分支】分支合并之后暂时不需要dev分支了,所以删除掉dev分支：git branch -d dev
●【master分支】虽然此时本地仓库的dev分支删除了,但是远程的 GITHUB上的dev分支还是存在的,应该考虑将远程的dev分支也同时删除掉：git push origin --delete dev
3.分支合并模式：对于默认的分支合并模式来讲,所有的日志信息是无法进行详细记录的,因为默认的分支采用的是“ Fast-forward”合并模式,这种合并模式虽然比较迅速,但是最大的问题在于,无法进行详细的分支处理的记录,所以此时在进行分支合并处理的时候最好不要使用默认的模式,而应该采用的是“NO-FF”模式,如果使用NOFF模式它会在 Master合并分支上产生一个新的提交点,这样就可以完整的记录好当前分支的处理过程。
● 【master分支】创建并切换到dev分支：git checkout -b dev
●【dev分支】进行一些代码的修改操作，同时将修改提交到版本库之中：git commit -a -m "Add toString Method in Emp.java"
●【dev分支】切回到master分支上：git checkout master
●【master分支】合并dev分支,同时设置“no-ff”模式：git merge --no-ff dev 此时的合并模式不再使用“ Fast-Forward”,这样就会在 master分支上产生一个新的提交点,于是来观察当前的分支信息。
● 查看当前git日志中的所有分支信息：git log --pretty=oneline --graph