发布于 2015-12-28 08:48:59 | 436 次阅读 | 评论: 0 | 来源: PHPERZ
Git分布式版本控制系统
Git是一款自由和开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
git是一个版本控制工具，就要先弄清楚什么是版本
那一个commit又包含哪些内容，比如有一个文件里边的内容是：
京口瓜洲一水间
钟山只隔数重山
春风又到江南岸
明月何时照我还
后来改成了
京口瓜洲一水间
钟山只隔数重山
春风又过江南岸
明月何时照我还
那这次改动就是一次commit
可以理解为一个commit里边存的就是一个差异，比如上例就可以表示为：
-春风又到江南岸
+春风又过江南岸
这样我们就可以清楚的知道某个版本做了什么样的修改，同时还能知道这个时候文件的全部内容是什么样的
为了能准确定位到某个版本，git给每个commit一个独一无二的ID，比如a823b1这样的16进制数（可以只用前几位，只要唯一就行）
commit-ID的生成算法：使用当前版本的所有文件内容和父commit-ID算一个hash值
如果刚好有另外一个人也对源文件做了修改：
-春风又到江南岸
+春风又绿江南岸
那这时候就会有俩条版本线（分支）
┌──────过(a8)
到(c3)
└──────绿(b2)
括号里是commit-ID
git实现版本线的方法很巧妙：
HEAD=a8
|
┌──────过(a8)
到(c3)
└──────绿(b2)
|
HEAD=b2
比如:
a8a8的commit，查到他的父commit-ID为c3这样就可以形成一条分支线
分支原理很重要几乎所有神乎其技的git操作都是通过它实现的
这个时候俩条版本线是孤立的，如果只是这样简单的各干各的，那咱们的教程也就《全剧终》了
可惜原作者采纳了绿的建议，但也要对过做记录，这时候就该版本管理工具提供的更加强大的功能协作出马，我们一起为同一个项目添砖添瓦，然后统一意见（分支合并）
合并后的整个版本变更过程就变成：
到 过 绿
git合并分支有俩种办法：merge,rebase。在git使用中不用merge是可以的，但rebase是必须技能，所以本教程只讲解rebase，merge请参见其他教程。
整个合并的步骤：
b2所在的分支上操作（因为他是最终的修改）b2的变更加到a8后边b2的 父commit-ID 设置为 a8b2算一个新的commit-ID 1e1e如下所示：
HEAD=a8
|
到(c3)──────过(a8)──────绿(1e)
|
HEAD=1e
在git中我们一般会使用master分支作为主分支（成熟的分支），平常我们会在master分支上支出来一个新的不成熟分支进行开发，以便在遇到bug或者新需求时再基于master拉一个纯净的分支，这些分支都是存储于本地库中，除了本地库还有远程库、远程镜像库
就是我们的git服务器，他其实和我们的本地库是一模一样的存在，它和每个人的工作目录没有任何区别，只是我们把这台机器作为中心节点汇总我们的改动。默认名字是origin。
git是一个离线版本控制系统，它设计了很多功能以支持离线工作。远程镜像库顾名思义就是远程库的一个本地镜像，我们不可以修改它，只能让他更新。这样所有读取远程库就变成本地操作。
git fetch 更新远程镜像库
git brannch 显示所有分支，以remote打头的都是远程镜像库里的分支（像上边说的我们无法直接查看远程库中分支）
git不能更新库。操作的对象只是分支和commit，我们只是用本地分支合并远程分支，也就是让本地分支包含远程分支的所有commit，也就达到了更新本地分支的效果（是不是和合并本地分支是一样的道理）
具体操作：git rebase origin/master
将我们的master分支更新到和远程master一样后就可以推送commit到远程库
git push orgin master 将本地master分支推送到远程库（以及远程镜像库）master分支
其他的远程分支其实和master分支是一样的，只是我们使用master作为最成熟的代码分支。如果怕电脑硬盘坏导致未推送到远程master的 代码丢失，我们就可以push到远程其他分支保存我们的分支。或者是几个人公共开发同一个功能也需要一个远程分支来汇总大家的工作进展
本文都是一些概念用于大家对git有一个总体的理解，具体操作还需查看pro git、git help或其他教程。