git第十三讲基于github的协同开发基础

使用github的主要目的肯定是为了多人可以进行协作开发,这一部分首先简单介绍一下git协作开发的基础,下一部分再来深入探讨基于分支开发的模式。

设置协同开发人员

在这里我们分别使用两个用户来模拟整个开发的流程,此处使用ynkonghao和kh121两个用户来进行模拟。

首先使用kh121创建一个项目p1,创建时选择初始化操作。创建完毕之后需要做的第一步是把协作的开发人员加入到项目中,选择settings

github协同开发基础
github协同开发基础

之后选择Collaborators添加合作者,将ynkonghao这个用户添加进去

github协同开发基础
github协同开发基础

添加完成之后,提示需要等待对方进行验证。

github协同开发基础
github协同开发基础

如果对方打开了通知提醒就会在页面上有一个提醒的消息,如果没有打开通知提醒,就需要等待邮件提醒

github协同开发基础
github协同开发基础

此时选择接受邀请之后,就可以开始进行协同开发。

github协同开发基础
github协同开发基础
github协同开发基础
github协同开发基础

协同开发的基本流程

首先分别用两个用户clone网络中的项目,首先使用kh121用户在项目中添加一些内容,之后完成提交。

##从远程工厂克隆p1项目
[root@localhost test]# git clone https://github.com/kh121/p1
Cloning into 'p1'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
[root@localhost test]# cd p1
##创建一个文件夹,添加一些文件
[root@localhost p1]# mkdir kh121
[root@localhost p1]# cd kh121
[root@localhost kh121]# echo a > a.txt
[root@localhost kh121]# cd ..
##提交版本
[root@localhost p1]# git add .
[root@localhost p1]# git commit -m "kh121 first commit"
[master 829fff8] kh121 first commit
 1 file changed, 1 insertion(+)
 create mode 100644 kh121/a.txt
 ##推送到服务器端
[root@localhost p1]# git push

此时查询一下github上的信息,发现已经完成了一次提交

github协同开发基础
github协同开发基础

接着使用另外一个用户ynkonghao进行一些修改之后提交,注意此时远程的版本已经修改,而ynkonghao这个用户的本地版本依然没有获取到远程版本的信息。

E:/study/git_2016/11/p1>git push origin master
To github.com:kh121/p1
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@github.com:kh121/p1'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

提示提交失败,因为远程的版本和我们自己的版本不一样,所以在提交之前需要进行pull操作,先完成本地版本和远程版本的同步。

E:\study\git_2016\11\p1>git pull ##同步远程版本
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), done.
From github.com:kh121/p1
   17de85d..829fff8  master     -> origin/master
Merge made by the 'recursive' strategy.
 kh121/a.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 kh121/a.txt

E:\study\git_2016\11\p1>git lg ##通过log可以发现会下载远程版本,并且合并到自己的版本中,而且远程的版本是有kh121提交的
*   60d9083 - (HEAD -> master) Merge branch 'master' of github.com:kh121/p1 (4 seconds ago) <ynkonghao>
|\
| * 829fff8 - (origin/master, origin/HEAD) kh121 first commit (23 hours ago) <Your Name>
* | fc0c200 - ynkonghao first commit (23 hours ago) <ynkonghao>
|/
* 17de85d - Initial commit (23 hours ago) <kh121>

执行了git pull之后会从github上下载远程的版本下来,之后和本地的分支进行合并,接着再通过push就可以完成提交。

E:\study\git_2016\11\p1>git push origin master
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 672 bytes | 0 bytes/s, done.
Total 7 (delta 0), reused 0 (delta 0)
To github.com:kh121/p1
   829fff8..60d9083  master -> master

此时另外一个用户如果希望提交他的版本,同样也需要进行pull操作,所以在实际的应用中,我们每一次push操作都需要先进行pull,从远程仓库把数据拉取下来。这个操作其实和svn类似,在commit之前需要进行update。同样也无法避免冲突问题。

远程协作的冲突问题

原则上每个用户都应该只负责自己的模板,这样尽可能避免冲突,但在实际的开发中依然无法完全避免冲突,接下来演示一下冲突的情况,首先让两个用户的版本都同步

github协同开发基础
github协同开发基础

目前两个用户的版本完全一致,此时在kh121用户中,修改common文件夹中的文件内容。

[root@localhost p1]# cd common
[root@localhost common]# ls
a.txt
[root@localhost common]# echo aaa >> a.txt ##添加一些内容到a.txt中
[root@localhost common]# cd ..
[root@localhost p1]# git add .
[root@localhost p1]# git commit -m "common update by kh121"
[master b374a56] common update by kh121
 1 file changed, 1 insertion(+)
[root@localhost p1]# git push origin maste

此时让ynkonghao的文件夹同样也修改common中的a.txt,然后进行pull,这里故意让a.txt的相同位置进行了修改,所以就会出现冲突

E:\study\git_2016\11\p1\common>echo aa >> a.txt
E:\study\git_2016\11\p1\common>more a.txt  ###在相同的位置进行了修改
a
aa

###完成了提交操作
E:\study\git_2016\11\p1\common>cd ..
E:\study\git_2016\11\p1>git add .
E:\study\git_2016\11\p1>git commit -m "update common by ynkonghao"
[master 46bde5f] update common by ynkonghao
 2 files changed, 2 insertions(+)
 create mode 100644 a.txt
 create mode 100644 common/a.txt

###进行了pull操作之后,发现了冲突
E:\study\git_2016\11\p1>git pull
Auto-merging common/a.txt
CONFLICT (add/add): Merge conflict in common/a.txt
Automatic merge failed; fix conflicts and then commit the result.
E:\study\git_2016\11\p1>cd common
###显示了aa这两个字符是在本地的header版本中编写的,而aaa是在id为b374xx的版本中编写的。
E:\study\git_2016\11\p1\common>more a.txt
a
<<<<<<< HEAD
aa
=======
aaa
>>>>>>> b374a565af1a1287394a2e079ae2e0708719e168

这种冲突问题就得由开发人员手动解决,整个流程和svn基本类似,如果仅仅只是按照上述的开发进行版本管理,在一个容易协调的团队中是没有问题的,但是如果在互联网中就会感觉版本稍微有些混乱,此时利用好分支模型就比较的重要,下一部分将会详细讲解基于分支模型的开发。

这部分的内容讲解了如何进行协作开发,并且分析了协作开发的流程,整个流程和svn类似,都是在push之前进行pull操作。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 1.git的安装 1.1 在Windows上安装Git msysgit是Windows版的Git,从https:/...
    落魂灬阅读 12,718评论 4 54
  • 文/菡萏莲荷 雪做衬纸,天为衬布,一组枯枝,跃入眼帘。 四季有轮回。心有春夏秋冬,便拥有了生命给予我们的本真与怡然...
    菡萏莲荷阅读 509评论 0 0
  • “江山风雨飘渺啊……唉……”一白发老者伴湖座亭而坐,神色忧愁,抚须长叹。 “阿爹,江山管它做甚?现在阿爹退隐江湖...
    蒼潇阅读 374评论 0 1
  • 格非江南三部曲阅读完毕。祝秀米、谭功达、谭端午三代人的命运变迁正是中国近现代史的浓缩写照,心得如下:改革者最难...
    糖豆角阅读 1,540评论 0 0
  • Unit Test What 什么是单元测试 Why 为什么要做单元测试 How 怎么做单元测试 What is ...
    Qingzh阅读 526评论 0 1