使用github的主要目的肯定是为了多人可以进行协作开发,这一部分首先简单介绍一下git协作开发的基础,下一部分再来深入探讨基于分支开发的模式。
设置协同开发人员
在这里我们分别使用两个用户来模拟整个开发的流程,此处使用ynkonghao和kh121两个用户来进行模拟。
首先使用kh121创建一个项目p1,创建时选择初始化操作。创建完毕之后需要做的第一步是把协作的开发人员加入到项目中,选择settings
之后选择Collaborators
添加合作者,将ynkonghao这个用户添加进去
添加完成之后,提示需要等待对方进行验证。
如果对方打开了通知提醒就会在页面上有一个提醒的消息,如果没有打开通知提醒,就需要等待邮件提醒
此时选择接受邀请之后,就可以开始进行协同开发。
协同开发的基本流程
首先分别用两个用户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上的信息,发现已经完成了一次提交
接着使用另外一个用户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。同样也无法避免冲突问题。
远程协作的冲突问题
原则上每个用户都应该只负责自己的模板,这样尽可能避免冲突,但在实际的开发中依然无法完全避免冲突,接下来演示一下冲突的情况,首先让两个用户的版本都同步
目前两个用户的版本完全一致,此时在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操作。