魔都的梅雨季简直了！对于杨梅爱好者来说，这是一个幸福的季节，然而，对于一个北方的妹子，实在忍受不了他的“诗”。每到下雨天，最怕的就是衣服、鞋子被打湿，可是昨天在网上看到一张照片后，雨天阴霾的心情瞬间放晴。只要心情是晴朗的，人生就没有雨天。

　言归正传，开启我的Git学习之路喽。。。。。。

Git的版本控制之道

Git作为一种新型的，轻量级的分布式版本控制系统（DVCS），深受攻城狮们喜爱。版本控制系统就好比银行的保险箱，保管价值连城的资产。而对于程序员来说，源代码就是这样的资产，由版本控制系统来保管。在Git的世界里，可以随身带着有自动提款功能的保险箱周游世界，这意味这你可以完全断开跟别人的连接独立工作，也可以在必要的时候与大家共享工作成果。

版本库

版本库是版本控制系统中用来存储所有历史数据的地方。下面对集中式版本库和分布式版本库做一下简要对比

集中式版本控制系统：比较代表性的是SVN，在这种模式中，所有程序员都会把他们的改动提交到服务器上的一个公共版本库中。具体来说，每一个程序员在本地都会有一个工作目录树，其内容是该版本库中最新的代码，当他们在本地工作目录树完成修改后，要把改动提交回公共版本库中。

分布式版本控制系统：以Git为代表，在这种模式中，每个人在本地都会有自己的版本库，而不是连接到服务器上的一个公共的版本库，所有的历史纪录都存储在本地版本库中，向版本库提交代码无需连接远程版本库，而是记录在自己的版本库中。如果程序员之间要传递各自的修改，可以通过Git的"push"操作直接把修改上传到主版本库。

所以，集中式版本控制系统就好比程序员公用一个保险箱，而分布式版本系统就好比每个程序员都有自己的个人保险箱。

工作目录树（Working Tree）

工作目录树是版本库的一个“断面视图”，包括开发该项目需要的全部文件。对于如SVN，工作目录在本地，版本库在服务器上，而Git中并非如此。在Git中，版本库不在服务器上，而存储在本地工作目录树的“.git”目录中。

那么，工作目录树是怎么创建的呢？有两个方法：第一个方法使用Git相关命令初始化版本库，生产“.git”目录；第二个方法是clone一个已有的版本库，也就是连带创建了相应的工作目录树。

代码修改与文件同步

每次提交操作都会使的版本库中新增一个版本，除了记录改动的内容外，还会记录改动的日志信息，即提交留言commit message，方便将来查询做这个改动的原因。

Git除了把改动提交到本地版本库之外，还要通过某种方法将改动共享，为此，必须把改动push到公共版本库中。

如果要实现代码同步，需要两步操作，推入操作只是其中的一步，在推入之前必须要要把别人的改动从公共版本库中拿入到自己的版本库中。把远程版本库中改动拿到本地版本库需要两步操作，第一步，把改动取来（Fetch），把远程版本库中的版本和分支复制到本地版本库；第二步，在自己的版本库中，把远程取来的改动与自己的改动合并（Merge）。在Git中可以用一个命令完成这两部操作，即Pull。

在最底层，Git记录和跟踪版本库中组成文件的各部分内容，并不是把整个文件作为不可分割的整体来记录和跟踪，而是记录和跟踪文件的各部分内容，也就是字符和代码行。

可以使用标签来跟踪里程碑，用来标记版本库历史中某个特定的点。比如对外发布的版本

介绍分支（Branch）与合并

分支

版本库类似于一本可以从头到尾按顺序阅读整个故事的书。而版本库中的分支就好像那种测试类的题目，选择不同的选项会跳转到不同的题目，可以有多种发展方向，各自形成不同的历史轨迹。

 主分支（Master）是研发的主线。分支可以合并到别的分支。

合并

合并即把两条或两条以上的分支合并到一起。Git比较各分支上的变化，确定变化在哪里发生，当不同变化发生在文件的不同地方时，Git可以自动合并。当Git不能自动合（即当不同程序员修改了同一文件的同一行代码时）并是就会提示冲突（conflit）。

分布式版本控制系统使用的锁机制是乐观锁，运行多个程序员同时修改同一个文件。

欢迎来到Git的世界