程序员与Github之间的暧昧-分支管理（二）

等，是一个无聊也无意义的过程。

这是我的第五篇原创文章

大家好，这是我github笔记的最后一篇，也是整个git学习的重点，这篇我们来聊聊补丁和如何用git来做多人协同开发的问题。

git的多人协同开发能跨空间的进行，现在的开源社区绝大部分都是用这种模式，他们彼此没碰过面，但是能进行协同开发。在之前，我们在学校学习的时候，大多是直接打包源码，发送给某个人，最多写个readme告诉他这个版本的功能是什么，添加了什么。

现在我们来了解下git的多人协同开发和补丁这个功能。

分支的处理实际上是为了更好的多人开发做出的准备，那么下面将利用两个命令（模拟其他的开发者）进行项目代码的编写。在讲解之前首先说明一下：

·一般而言，master分支项目的核心分支，只要进行代码的克隆，那么此分支一定要被保存下来；

·开发者往往会建立一系列的分支，譬如，我个人建立一个brh的分支进行代码的编写；

·如果要进行调试可以建立一个bug分支；

·如果要增加某些新的功能则可以建立feature分支。

下面我们来进行模拟的一个多人开发环境。

1

【开发者一】创建并切换分支

创建并切换分支：

git checkout -b brh

2

【开发者一】新建文件并提交修改

新建几个文件或者修改文件用下述指令

git add .

git commit -a -m 'add some file'

3

【开发者一】上传两个分支

上传主分支：

git push origin master

上传brh分支：

git push origin brh

4

【开发者一】推送远程服务器

git push origin xxx(待提交的分支名)

提交服务器的前提是，本地必须有自己的分支，才能提交。只有第一次提交要加 '-u' 参数，之后提交并不用加这个参数。

5

【开发者二】克隆

为了模拟第二个开发者，所以建立一个新的命令窗口(到其他文件夹，或磁盘)，并且将代码克隆。

git clone xxx(地址)

6

【开发者二】查看分支信息

git branch -a

我们会发现,现在只是将master分支拷贝下来，但是分支并没有存在（本地分支）。

7

【开发者二】创建分支

git checkout -b brh

8

【开发者二】brh分支拷贝

git merge origin/brh

将服务器端上的brh分支拷贝到本地brh分支。

9

【开发者二】新建或修改、提交

git add . (添加文件)

git commit -a -m 'add some file'

10

【开发者二】推送服务器

git push origin brh

因为现在本地brh分支代码发生了变化，应该提交到本地。这个过程模拟第二个人修改了代码，但是第一个人存在版本落后的问题。

11

【开发者一】拉取最新版本

git pull

这个时候最原始的开发者目录下还只是上一次提交的内容。说白了，就是版本落后了。那么需要取得最新的数据才可以。

对于取得最新的分支数据有两种方法：

·git fetch:此操作只是取得最新的分支数据，但是不会发生merge合并

·git pull: 此操作取得最新分支数据，并且同时发生merge合并操作。

实际上错误信息也很简单，指的是当前的brh分支和服务器上的分支并没有关系，所以如果想要读取代码，必须让两个分支产生关系。

git branch –set-upstream-to=origin/brh

随后再次git pull

这个时候一号就能获取到最新版本的代码。

12

【开发者二】修改文件，并提交，推送

提交修改：

git commit -a -m 'modified some file'

向服务器提交代码：

git push origin brh

13

【开发者一】修改文件，并提交

提交修改：

git commit -a -m '2 file updata'

很明显，这两个用户一起修改了同一份文件。

14

【开发者一】跟新最新数据

拉取：

git pull

现在可以发现，此时的程序，是两个开发者修改同一个代码，所以产生了冲突，同时一号开发者之中的文件内容已经变更。

15

【开发者二】手动修改冲突，并提交

手动解决冲突文件内容（看什么需要保留，自己留一下就行）。

提交：

git commit -a -m 'updata code'

推送服务器：

git push origin brh

现在已经成功的由本地的冲突扩张到了远程冲突，相信通过这么讲解大家能更好理解分支操作的问题。

上面是模拟一个简单的开发实况的基本git操作。下面把要做笔记的左后一部分讲完，就是补丁。

补丁并不是针对所有代码的修改，只是针对局部的修改，在很多的代码维护中，如果按照最早克隆的方式将代码整体的克隆下来，实际上花费的资源还是比较大的，但是修改的时候可能只修改很小的一部分代码，所以在这种情况下就希望可以将一些代码的补丁信息发送给开发者。而发给开发者之后他需要知道那些代码被修改了，这样的话就可以使用一个极低的开销实现代码的修改操作，而在git之中也提供了两种简单的补丁方案：

·使用git diff 生成标准的path

·使用git format-path生成git专用的patch

1

利用git diff 生成标准的patch

(1) 建立一个新的分支—cbrh，并修改add.c内容

(2) 观察前后代码有什么不同

git diff add.c

这时候可以看到add.c代码修改前后的比对

(3) 在cbrh上进行代码的提交：

git commit -a -m "change file"

此时并没有和主分支进行提交，因为代码已经改变了，需要的是将代码的变化提交给开发者。

(4)生成补丁文件 – my pat

git diff master > mypat

(5)切换为master分支 git checkout master

此时会自动在项目目录中生成一个mypat的补丁文件信息，这个文件是可以由git读懂的信息文件，那么完成之后现在需要模拟另外一个开发者，另一个开发者假设是专门进行补丁合并的开发者。

(6) 创建并切换一个新的分支

git checkout –b patchbrh

(7)应用补丁信息

git apply mypat

这时候的补丁可以成功使用了。

(8)提交补丁操作

git add .

git commit –a –m “patch apple”

(9) 切换回master分支之中进行分支合并

git checkout master

git merge --no-ff –m “merge patch” patchbrh

这样如果将补丁数据的文件发送给开发者，那么就没有必要进行大量的代码传输，并且在创建补丁的时候也可以针对于多个文件进行补丁创建。

2

利用git format-patch 生成git 专用补丁

那么下面还是利用分支修改add.c文件。

(1) 创建并切换到cbrh

git branch –D cbrh

git branch –D patchbrh

git checkout –b cbrh

(2)修改文件

(3)提交修改：

git commit –a –m “add some code”

(4)下面需要与原始代码做一个比较，而且比较后会自动的生成补丁文件。

git format-patch –M master

此时已经生成一个补丁文件，因为只修改一次的内容，这个补丁文件严格来说就是一个email数据，需要将此数据发送给开发者，而后开发者可以进行补丁应用。

(5) 创建并切换到patchbrh 分支上

git checkout master

git checkout –b patch

(6) 应用补丁的信息，利用“git am”完成

git am 0001-add-some-code.patch

现在是将发送过来的，带有email格式的补丁进行了应用。

(7) 提交应用的更新

git commit –a –m “method patch apply”

那么此时 就可以成功的应用补丁进行代码的更正。

3

两种补丁的应用说明

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

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

如果你是一个做软件相关的工作，建议学学git,这个工具比较实用，也切合工作。之后我的笔记可能就有点凌乱，因为在工作中用到，有想到，就写点的那种。

总结

在整个git中，分支的管理是最麻烦但是这个是最重要的操作，所以这部分可以反复查看，分支是进行开发使用的，最终必须都在master上，这点最重要，切记。

分支的协同使用建议多熟悉下，这个使用在工作共长用到，比如晚上下班前将代码提交，第二天来上班第一件事儿一定是将最新的版本拉取，然后才进行开发。

-END-

转载是一种动力 分享是一种美德

感谢您抽出·来阅读此文