Git分支管理

• git的分支管理是github多人协作的核心，它实现了将多个人对同一项目，不同时间线里的修改，进行快速整合统一，而且不会相互影响*

• 前面说过，git的提交是在版本库里，版本库分为 暂存区 和 master分支 ，但更严谨地说，HEAD不是指向当前版本，而是指向 master
  每次提交commit，git都会把版本串成一条时间线，这个时间线就是一个分支，若只有一条时间线，这个分支就是 master分支
  
  这就像一个链表，每次提交，就尾插一个新节点，而master就指向该节点

• 当我们创建新分支时，git会新建一个指针* 假如是 dev * ，指向master相同地提交版本，再将HEAD指向dev,表示当前分支是 dev

• 
  
  从指令上体现，就是创建了新的分支，并且HEAD 指针指向 dev

而且，接下来对工作区的修改，就是在 dev的分支上进行了

上面在dev分支下，对readme.txt文件进行了修改，并且提交；在返回 git switch master分支后，发现没有发生任何修改，这说明，不同分支下的修改，是不同步的，可以理解成两个指针，指向两个实例化的对象，实例化内容不同

• 但同时，不同分支其实也可以合并，合并的方式有些差异，例如：

1. 直接合并 git merge dev
   将相当于master指针直接指向最新的 dev
   
   看上面提示的 Fast-forward，说明这是向前合并，也称“快进模式”，这种合并方式直接，很快，但是，不是所有情况都适合这种粗暴的改指针指向的做法。

2. 手动解决冲突后合并
   这种情况发生于，不同的分支，对同一个文件进行的修改，从而发生冲突，不知如何合并！
   例如：

   
   上面在dev 分支进行了修改

   
   然后回到master分支，又对readme.txt文件进行了修改，想直接合并的时候，出错了，这是不对的，需要手动解决冲突，才能合并。

   

   执行 git status可以查明冲突在哪里，同时，打开文件，还有提示两者的冲突是上面，方便进行修改

   

   我们根据提示，对该文件进行修改
   
   还可以用日志查看合并过程

2783557200