写在开始之前
本来想写一篇短文的，结果发现可写的东西挺多，最终就写成了一个小系列教程，目录如下：
- git使用简明教程（一）：Branch和Merge的概念
- git使用简明教程（二）：git中常见概念
- git使用简明教程（三）：github使用实战演练（文科妹子篇）
- git使用简明教程（四）：git及github实战演练（理科汉子篇）
- git使用简明教程（五）：fork功能的使用
本篇为第一篇，其他两篇完成后也会将链接更新到这里。enjoy
今天做了一件挺傻逼的事。
最近我在写一个插件。加班加点写出了一个最初最初的版本，也有热心的朋友愿意帮我测试一下。你猜的没错，这位热心人士就是 
今天做的傻逼事就是明明自己说了让别人帮试用一下，自己却把代码改了。增加了新功能，处于新功能还没有开发完成，旧功能（想让别人测试的功能）已经不能用的状态。如果这时
遇到这种问题怎么办呢？其实github早就给出了解决方案了，那就是新的branch。
1、Branch的概念
branch是什么呢？字面意思是分支。
在某些软件公司，同一个产品下面会有两波人，一波负责维护稳定版的产品，一波负责开发新功能。这就是天然的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的时候感觉闷头走了不少弯路，自己的教程能让一个人少走一点弯路也算是很大的成就了。希望大家支持。