git分支合并相关

Git在处理冲突的相关操作

1. 分支介绍

  以下是两个分支的图片。不管在哪个分支上，每次push必须是在最新的节点。例如如果在master分支上提交代码，那么当前节点一定是C6。

  因此在团队开发中，为了保证自己push时的状态是最新的。每次push之前必须pull。

2. 冲突产生的原因

  两个开发人员更改了同一份代码。第一个人已经将代码push到了远程仓库，后一个人在pull的时候就会发现远程仓库的代码和本地着不同的地方。这个时候git就会提示产生了冲突。必须解决之后才能提交。

3. 单分支冲突

  3.1 merge方式

  使用commit ->pull->push方式，因为idea默认是merge解决冲突。这里首先提到merge方式。
  这里因为本地也是有一个git仓库的。这里首先将代码commit到了本地仓库，再从远程仓库拉取代码时，便会产生冲突。只有解决后才能push。
  这里也是举例说明。首先Jay新建了一个仓库，同时初始化了三个Java文件。这时Green将代码拉取了下来。这时Jay对其中两个文件做了修改，并push上了远端仓库。

  这时green同学也对Main和Test1进行了修改。



  当他commit之后，pull的时候就出现了如下冲突：



  这个时候点击merge按钮，依次对出现冲突的文件进行merge操作即可：
  第一种方式是对照代码选择合并。这里要小心操作，一般让出现冲突的两人一起解决。



  第二种方式是选择某一方的代码作为最终版本。

  处理完毕之后进行commit->push即可完成。之后代码会作为最新的节点。

  3.2 rebase方式

  这里rebase方式操作指的是也是commit->pull->push方式，只是合并分支的操作使用的是rebase。
  在开始讲之间简单介绍一下rebase操作。rebase操作是将当前的更改保存到Git栈中，并将代码回退到远端仓库的状态。之后将代码从栈中取出代码，并将代码合并到当前状态，这里可能就会出现冲突。它对比merge最大的优势是分支是一条完整的线，且顺序明确，而不是交叉的方式。更加美观，具体看后文中配图。
  这里继续用以上例子接着进行介绍：在解决冲突之后。Jay和Green的版本已经一致，这里Jay再次对Test1进行更改，如下图。这里午休时间较短，具体流程晚上完善。
  下图是处理冲突时选择rebase。



  下图就是merge和rebase两种处理方式在分支结构上的差异。

  3.3 git操作基本快捷键

1. commit： ctrl+K

2. push：ctrl+shift+K

3. rollback：ctrl+Alt+Z

4. 打开处理冲突的窗口：先双击shift打开搜索，之后输入conflict。
   
   

3.分支合并

  这里以简单的二分支合并来作为介绍。这里以一张图片直观的展示合并分支的结果。

  这里我新建了一个test分支。
  在test分支上对Test2进行了修改。之后将它push到了远程test分支。
  同时在master分支上对Test2也进行了修改。之后将它push到了远程master分支。
  之后将本地的test分支合并到master分支，这里显然有冲突。具体操作见下图：









之后push到远程master仓库即可。
需要注意的是，这里的操作仅是将本地的test分支合并到了本地master分支。只要在合并之前将本地test和远程test保持一致。那么意义是一样的。