一、问题
对于一个项目,如果需要多人协同开发,大家都在原始仓库中进行修改提交,经常会发生冲突,而且一不小心会把别人的代码内容覆盖掉。为了避免这样的问题,git提供了fork-merge request这样的协同方式。
二、仓库框架模型
- 首先git仓库分为远端仓库和本地仓库分别对应上图的remote和local。
- source repository表示项目的原始仓库内容,一开始只创建了这一个仓库,是大家进行fork的起点,也是用于构建、发布的仓库。
- 每个参与者在source repository的基础上fork一个新的远程仓库user repository,其内容与当前source repository相同,但是他是独立出去的新仓库,后续除非手动更新,否则不会随着source repository同步。
- 通过git clone user repository命令,将user repository克隆到本地,也就是local repository。此时local repository只与user repository绑定,而与source repository没有任何直接联系。
并且通过git remote -v可以看到只有一个origin仓库,关联user repository的url。
- 之后再通过git remote add origin_src source repository,将source repository与local repository绑定,并设置名称为origin_src(这里名称可以随便取,只要与原有的origin重复即可)。
再通过git remote -v可以看到除了origin仓库外,还有有一个origin_src仓库,关联source repository的url。
至此,仓库就搭建好了,可以在本地进行开发,后续进行提交与合并。
三、开发、提交流程
3.1 提交与合并
- 在local repository开发完成后,通过git add和git commit命令完成本地仓库的提交记录。
- 然后通过git push origin master命令将local repository的master分支内容推到user repository中。
- 然后再从浏览器进入user repository,发起merge request,请求将user repository的master分支内容合并到source repository的某个分支(如master)中。
而在发起这个请求后,并不会直接合并,而是处于待合并的状态,并且可以指定相关人员对合并内容进行审阅,确保合并代码符合规范,并且不会对其他代码造成影响。
除此之外,如果当前内容与source repository内容存在冲突,则需要解决完冲突后才能合并。(需要再本地拉取source repository代码,解决完冲突后重新提交到user repository中,如果之前的merge request没有关闭,则会将当前提交记录更新到刚刚的merge request中,然后就可以合并了。)
- 当审阅人员执行合并后,你的提交记录就会被合并到source repository啦。
3.2 更新代码
前面提到我们本地的代码都是直接推到user repository的,而且这个仓库一般仅仅是你自己拥有,所以一般不需要从这个仓库拉取代码(如果需要则使用git pull origin branch).
通常需要拉取的是source repository的内容,包含了其他人员提交的代码内容,拉取方式为:
git pull origin_src master
表示将origin_src仓库(也就是source repository)的master分支拉取到本地的当前分支下。master可以是任意分支名。
之后可以继续在本地开发,或者直接提交到user repository,用于同步source repository的内容。
三、优点
首先是前面提到的在提交merge request之后,有个待合并的状态,可以供他人审查。并且当出现问题时可以关闭当前请求,这是分支开发合并所不具备的。
其次是fork出来的user repository是完全独立的,完全可以在其上开辟新分支、打标签等操作,而不影响source repository,使得source repository更加干净。