等,是一个无聊也无意义的过程。
这是我的第五篇原创文章
大家好,这是我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-
转载是一种动力 分享是一种美德
感谢您抽出·来阅读此文
领取专属 10元无门槛券
私享最新 技术干货