Git 分支管理

第一、GIT工作原理：

master分支：

用分支操作：

当用户创建一个新的分支（假设新的分支为“brh”）后，GIT会建立一个新的brh指针，此指针将会指向master相同的提交，再将HEAD指向brh，就表示当前分支在brh上。

在整个过程中，发现HEAD的指针发生了改变，因为HEAD永远都要指向当前的分支（当前工作的分支），一旦创建分支，那么一定需要针对代码进行新的修改（再次提交）；

分支提交：

如果有新提交，则master分支不会改变，只有brh分支会发生改变

此时的master分支的版本号就落后于子分支了。但是不管子分支在怎么开发，也不是最新的发布版本，所有的发布版本保存在master分支上，就必须将子分支与master的分支合并！

分支合并：

当分支合并之后，实际上就相当于master的分支的提交点修改为子分支的提交点，而后这个合并应该在master分支上完成，而后HEAD需要修改指针，断开brh分支，而指向原来master分支；

删除子分支：

分支删除之后所有的内容也就取消了。

简单实现分支步骤：

1、git   branch   brh         #创建分支

2、git    branch                 #查看分支

3、切换到brh分支上

4、创建并切换分支

5、修改hello.php文件

<?php public function test(){echo "Happy New Year";} 

6、在子分支上将修改进行提交

再次切换到主分支

<?php public function test(){echo "你好吗？";} 

当再次切换到brh分支上的时候就会再次回到原来的代码

<?php public function test(){echo "Happy New Year";} 

当分支的数据提交之后实际上并不会去修改master分支内容，这就证明了，俩个分支上的内容是彼此独立的

7、将俩个分支提交到远程服务器上（GITHUB）

提交之后在服务器上查看俩个分支：

8、brh与master分支进行合并（一定要在主分支上）

这样实际上修改了master指针为brh分支的指针信息，所以此时的合并方式为【Fast-forward】，表示快速合并方式，快速的合并方式并不会产生任何commit  id，他只是利用了合并子分支的commit   id  继续操作；

9、此时执行删除brh操作，并且提交master分支   （亦可以用“-D”来强制性删除）

10、删除远程服务器上的brh分支 （还可以“git  push  origin  ：brh”来删除）

此时服务器上已经删除了brh分支

查看分支：

第二、冲突解决

当你的代码改动逻辑不是特别大的话，git可以自动给你解决，冲突大的话要用手动改

git   log   --graph   --pretty=oneline                                 #来查看解决冲突的历史

第三、分支管理策略

之前的合并全都是“Fast  forward”方式完成的，这种方式知识改变了master指针，可在分支的时候也可以不适用这种快合并，即：增加一个“--no-ff”参数，这样表示在合并之后会自动生成一个新的commit  id，从而保证了数据的完整性；

简单的实例：

master分支应该是非常稳定的，也就是仅用来发布新版本，不要在次分支上开发；

在各个子分支上进行开发工作；

团队中每个成员都在各个分支上工作。

第四、分支暂存

当我们要放下现在的任务去完成必然的任务时，我们可以先将现在的任务提交到暂存区中，完成别的任务以后我们可以用以下的命令来回复！

4.1、git   stash  list                                                 #直接可以列出所有的暂存状态

4.2、从暂存区之中进行恢复，暂存区恢复以后那么所暂停的操作将没有存在的意义，但是也有人会认为有意义，所以恢复有俩种方式：

方式一、先恢复，而后在手工删除暂存

git    stash    applygit    stash    drop

方式二、恢复的同时也将stash内容删除

git    stash   pop

那么下面的任务就可以像之前那样进行代码的提交，而后删除掉所在的分支；

这样就可以很好的解决代码中途暂停修改的操作！

第五、补丁：patch

补丁并不是针对于所有代码的修改，知识针对于局部的修改。只是将要修改的代码的补丁信息发送给开发者，而在GIT之中页提供了俩种简单的补丁：

1、使用git  diff 生成标准patch；

2、使用git   format-patch声称git专用的pat；

简单的实例：

                                                                       git   diff  生成补丁

5.1.1、创建一个cbrh分支

5.1.2、生成补丁

5.1.3、在cbrh分支上提交代码

5.1.4、生成补丁文件

5.1.5、在切换回master分支                            git   checkout   master

5.1.6、创建并切换一个新分支                          git  checkout  -b    patchbrh

5.1.7、应用补丁信息                                        git    apply   mypat                      （此时补丁可以成功的使用了）

5.1.8、提交补丁的操作                                    git   commit  -a  -m   "Pacth  Apple" 

5.1.9、切回master分支之中进行分支合并     

                                              git    format-patch 生成补丁

5.2.1、创建一个brh分支                                        git    checkout   -b   brh      

5.2.2、提交                                                            git   commit -a -m  "Add toString  Method"     

5.2.3、下面需要与原始代码做一个比较，而且比较后会自动的生成补丁

5.2.4、创建并且切换到patchbrh分支

git  checkout   mastergit  checkout  -b   patchbrh

5.2.5、应用补丁的信息，利用“git am ” 完成

5.2.6、提交应用更新

关于俩种补丁方式的说明：

1、使用git diff生成的补丁兼容性比较好，如果你是在不是git管理的仓库上，此类方式生成的补丁是非常容易接收的；

2、但是如果你是向公共的开发社区进行代码的补丁更正，那么建议使用git    format-patch，这样不仅标准，而且也可以将更正人得信息进行公布。

第六、多人协作开发

6.1、创建并切换到一个新的分支：brh

git   checkout  -b  brh

6.2、在新的分支上新建一个文件      dept.php

<?php public function dept(){echo "aaaaaaa";} 

6.3、将代码进行提交

6.4、将俩个分支提交到服务器上

git  push   origin  mastergit  push   origin  brh

6.5、模拟第二个开发者，创建一个新的命令行窗口，并且将代码克隆下来（F:procline）

6.6、【二号】查看分支信息

6.7、【二号】建立并且换到brh分支上

git   checkout  -b   brh

6.8、【二号】将远程服务器上的brh分支上的内容拷贝到本地brh分支上

6.9、【二号】增加一个admin.php文件

6.10、【二号】将新的代码进行提交

git  add .git  commit  -m  "Add  Admin.php File"

6.11、【二号】现在本地的brh分支代码发生了变化，将变化的代码提交到远程的brh分支上

6.12、【一号】现在这个时候原始的开发者目录下还是上一次提交的内容，那么需要取得最新的代码才行

     取得最新的数据有俩种方式：

    1、git  fetch ：此操作知识取得最新分支数据，但是不会发生master合并操作；

    2、git   pull  ：此操作取最新分支数据，并且同时发生master合并操作；

这表示当前的brh分支与服务器上的brh分支没有关系，要想得到代码必须让俩者之间产生关系，用以上的代码可以实现

6.13、【二号】修改admin.php文件，并且提交

6.14、【二号】向服务器提交代码的修改

6.15、【一号】也对admin.php文件进行了修改，并且提交

6.16、【一号】此时抓取最新的

此时俩个开发者同时修改了同一个文件admin.php，所以产生了冲突，同时一号开发者中的代码变为如下：

6.17、【一号】手工解决冲突文件内容

6.18、再次提交和服务器推送

此时已经成功地解决掉了冲突问题，“如有写的不好的地方请多多包含！”