git
是当今流行的版本控制工具,一般我们可能只要会push
,pull
就可以了,
但是当我们同别人共同工作的时候,我们必须要了解git
协同开发的一些重要流程.
前言 #
git
作为当今最流行的版本控制工具之一,当时开发出来就是为了管理Linux
庞大源代码的分布式版本控制工具.
由于Linux
源代码过于巨大,仅靠一个人的力量是完成不了的,那就必须把工作分配下去,然后将代码合并,所以git
一开始设计的时候就是一种分布式的、多分支的
概念 #
所以git
最重要的就是分支这个性质,分支是什么呢.
要了解分支必须要了解git
工作原理.
git
工作原理很简单就是add
、commit
,add
、commit
….,简单来说就是添加记录,添加记录,保存快照,添加记录,添加记录,保存快照
如上图,随着master分支快照的一个一个建立,软件就慢慢的迭代下去了
分支工作流程 #
接下来我们要着重讲一下分支,我们看到master
分支的v0.1
版本,我们已经开发出稳定的v0.1
版,这时候我们决定开发一个新功能.
在这里我们分了一个Develop
分支,我们在Develop
分支开发新代码.
这时候我们发现v0,1
的一个bug
,假如是没有使用版本控制的话,一般人会停下手中的活,然后从当前的新代码处来修复这个bug
,当这个bug
很简单的时候,我们不会遇到很大困难,但是当bug
藏的很深,而且新代码隐藏了这个bug
,或者被这个bug
影响,这时修复工作就变得很困难.
还好我们有git
,我们从v0.1
直接分一个Hotfix
分支,这两个分支的父都是v0.1
,我们直接从稳定版本修复,不牵涉到新代码,这样修改好后我们就能很快从Develop
分支继续工作了
而且这样有一个好处我们将master
和Develop
分支合并的时候很大可能不会产生冲突.
冲突(coflic)是什么了,怎么能避免呢?
从两个分支的父亲v0.1
看起,我们每次改动一个保存文件就会产生一个modify
(修改)的动作,我们假如分支里面都对同一个文件产生了modify
(修改)动作,当我们合并的时候这就是一个冲突,git
无法理解采用哪个分支的modify
动作,这时候就要你人工来修改采用哪个分支.
假如没有相同的文件有modify
(修改)动作,git
就会聪明的知道采用每个分支的最新的modify
(修改)修改出一份所以文件的最新版.
那我们怎么来避免这个冲突呢,这就要求我们分支要分的合理,分支只要完成特定的工作,不要越俎代庖,那有些人会说我这个分支一定要改父的耦合地方否则我的代码工作不了,这时我们要好好思考自己的分支的功能,把合并耦合的代码放在主分支里面,次分支只要完成特定功能就可以了,这样合并分支时候不但可以安全的merge
(合并)了, 而且修改bug
的时候也可以对症下药,直接在问题开始的地方修改.