前言

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的时候也可以对症下药,直接在问题开始的地方修改。

更多相关内容请点击查看原文