git使用简明教程(一):Branch和Merge的概念

写在开始之前

本来想写一篇短文的,结果发现可写的东西挺多,最终就写成了一个小系列教程,目录如下:

本篇为第一篇,其他两篇完成后也会将链接更新到这里。enjoy


今天做了一件挺傻逼的事。

最近我在写一个插件。加班加点写出了一个最初最初的版本,也有热心的朋友愿意帮我测试一下。你猜的没错,这位热心人士就是 @justyy 。在做开发的时候,多数时候测试,特别是让别人试用,都在和下一步的开发在同步进行。

今天做的傻逼事就是明明自己说了让别人帮试用一下,自己却把代码改了。增加了新功能,处于新功能还没有开发完成,旧功能(想让别人测试的功能)已经不能用的状态。如果这时 @justyy 试用了,他可能就很迷惑了,你让我来试什么?!什么都不能用!!而且在比较极端的情况下,功能不完整的插件还有可能还会损坏别人的博客。

遇到这种问题怎么办呢?其实github早就给出了解决方案了,那就是新的branch。

1、Branch的概念

branch是什么呢?字面意思是分支。

timg.jpg

在某些软件公司,同一个产品下面会有两波人,一波负责维护稳定版的产品,一波负责开发新功能。这就是天然的branch的概念,他们两波人的工作本质是维护两个branch。稳定版本的,我们可以放到主分支master上。这个分支一般是小的修修补补,首要任务是维护产品稳定运行。另一波人就是开发新功能,新版本,可以放到分支dev中这个branch中。他们可能会对产品进行大改,之后测试,最终形成一个有新功能的版本。

现在问题又双叒叕[yòu shuāng ruò zhuó]来了,dev这个branch这个版本已经开发的完了,为了稳定版本,这时应该怎么办?让负责维护稳定版本的那一波人来维护dev,然后开发组再开一个新的branch叫dev2??当然不是。

这里就出现了一个概念merge。

2、Merge的概念

merge的字面意思是合并,很好理解,现在分支dev也达到了稳定的状态,那么把两者合并就可以,合并后的master里面既有维护组修修补补的工作,也有新的功能,非常棒吧。

但大家有没有想过一个问题,那就是master在改变一个文件的同时,dev也有可能在改变这个文件,这时如何保证merge后文件的正确性呢?git中也有比较完整的冲突解决的机制,这个我会有最后的实例中和大家再好好说一说。

现在说说我遇到的这个问题,我可以保持master里面的内容是稳定,经过测试,对外发布的最新版本,也是让别人帮忙试用的版本。再新建一个分支,就叫beta_ver(汗,这个名字起的很差)吧,在beta_ver里面做开发,测试。

最后,突然觉得可以写一点使用github的教程,我使用github的时候感觉闷头走了不少弯路,自己的教程能让一个人少走一点弯路也算是很大的成就了。希望大家支持。

H2
H3
H4
3 columns
2 columns
1 column
5 Comments