git 分支管理

在实际项目开发的时候都一定会有项目的开发阶段：一期开发、二期开发......。而传统的恢复方式采用的是文件的拷贝操作完成，这样是非常不方便的，而git不仅提供了各种可用的分支操作（每一个分支都可能作为一个完整运行的项目出现）。也可以为项目的开发提供更加方便地支持。

分支的创建与合并

从正常道理来讲在Git之中会存在有大量的分支操作，而最为关键的分支是master分支，在git之中规定所有最终要使用的代码应该将其定义在master分支上。

但是在代码的开发过程之中一直想要编写，那既然master是主要的运行分支，那么一定不合适，因为只要编写代码就一定会产生错误与调试。master是给最终用户使用的。所以绝对不可能，所以所有的开发都是在子分支上。

这样的好处是每一位开发者都可以独立开发属于自己的分支操作，并且不会与其他开发产生任何冲突。

1.查看仓库可用分支：

git branch

默认情况只会存在有一个master分支，并且使用*来标记当前所处的分支。

2.创建一个新的dev分支（开发分支）：

git branch dev

3.如果要想进行代码的开发，那么是绝对不可能在，master分支上进行的，必须要在子分支上进行开发。

所以想要进行切换到dev分支上：

git checkout dev

现在切换到分支上，随后*也跑到了dev分支上（假设现在master分支不操作）。

4.在dev分支上编写一些新的程序代码

public class jianzhu{
	public static void main(String args[]){
		System.out.println("Hello 剑主");	
	}
}

此时在master分支上不存在有jianzhu.java文件以及内容，但是此时jianzhu.java文件是在dev分支的工作区里面，要想让其真正使用，想要将其提交到dev分支里面。

5.增加文件到暂存区而后提交版本库

git add . 

git commit -m "add jianzhu.java"

在dev分支上就将具备比master分支上更多的内容。

6.为了更加清楚的观察出分支之间的关系，下面将分支在master与dev分支上进行切换；

git checkout master

git checkout dev

7.切换回master分支随后进行分支合并：

git checkout master

git merge dev

此时代码实现了合并操作，但是当前所采用的方式是Fast-forward，而这种方式的处理方式效果如下图所示：

快速合并：

此种合并过程是最快的，但是未必是最好的，因为现在有一个前提：master分支没有进行任何的操作。

8.实际上任何的项目开发都不可能是一蹴而就的，可能会出现一个月所写的代码都在dev上，所以在进行远程仓库提交的时候就必须将所有的分支提交到服务器上。

合并master分支：git push -u origin master

合并dev分支：git push -u origin dev

如果是新分支则会出现new branch。

如果将分支提交到服务器上之后，那么在GitHub上也可以看见所有的分支信息。

9.当某一个分支不再使用的时候，可以删除分支：

git branch -d dev

10.如果说现在某一个远程分支不再想要使用了，应该一起进行删除：

直接删除：git push origin --delete dev

直接推送一个空的分支：git push origin:dev

 

冲突解决

只要使用GIT的情况下，绝对不允许去修改master分支，也就是说所有的更改操作不能在master分支上完成。

既然存在有分支的概念，那么就一定有可能出现这样的一种情况：两个分支同时修改了同一个文件，那么这两个分支在进行合并的时候就一定会出现冲突。

1.创建并切换到dev分支上：

git  checkout -b dev

此命令等价于：git branch dev   加上   git checkout dev。

2.在dev分支上建立一个新的文件：jcn.java ，同时修改hello.java文件；

3.在dev分支上把工作区中的修改内容提交到版本库中：

git add .

git commit -m "change hello.java in dev branch"

4.切换为master分支上，并且也针对于hello.java文件进行修改,随后将修改提交：

git checkout master

git add . 

git commit -m "change hello.java in master branch"

5.在master分支上合并dev分支：

git merge dev

两个分支都对hello.java进行了修改。

此时命令执行完毕后直接会显示出合并的结果：CONFLICT (content): Merge conflict in hello.java

在hello.java合并的时候出现了冲突。

此时由于存在有冲突，所以不能够进行分支的合并，随后在hello.java文件中出现了如下内容：

现在可以发现所有冲突的代码都明确的标记在了冲突的文件里面。当解决了冲突之后，查看当前状态：

6.重新进行更新的提交：

git commit -a -m "conflict file"

查看状态：

提示是否需要将操作发送给master分支上：

git push -u origin master

 

分支合并模式

对于分支的合并模式，在之前已经观察到可以使用”Fash-forward进行快速的分支合并，但是这样的分支合并有一个缺点。

范例：通过图形化的方式来查看所有的分支合并记录：

git log --graph --pretty=oneline

如果觉得以上的命令行显示不习惯浏览，可以打开GUI 工具查看。

Repository——>Visualize Add Branch History

为了可以清楚的发现问题，再合并一次分支。

建立一个dev分支：

git branch -d dev

git checkout -b dev

在这个分支上进行代码的修改，随后进行提交。

git add .

git commit -m "test"

切换回master分支，而后与dev分支进行合并：

git checkout master

git merge dev

此时又合并了一次分支，随后查询分支状态：

发现此时分支合并之后与之前没有任何的区别，因为默认情况下的”fast-forward“分支合并方式不会产生一个新的提交点。

默认情况下分支合并不会产生提交点信息日志。

但是这样的操作并不合理，因为为了保证操作记录的完整性，应该可以将所有的分支合并过程进行详细的描述：

在合并的时候加上 ”-no-ff“参数：

重新删除并创建再合并：

比较示例：

比较对象：git merge --no-ff -m "use no-ff Merge" dev

此时分支合并之后产生了一个新的提交点。

总结：在实际工作中的分支操作

不允许在master分支上进行开发，master分支会作为项目的最终形式发布。

在master分支上可以建立一个dev的子分支进行项目的开发，但是需要记住的是，从实际情况来讲每一位开发者不允许直接在dev直接编写，应该在dev中创建新的子分支进行编写。

每一个分支可以进行分别合并，最终一定要在dev分支上调试完毕之后再合并到master分支，并且一定要使用”--no-ff“的合并模式，产生新的提交点。