Git简介和基础操作
??? 像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。如果任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地 仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份：
????????????? Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。对于任何一个文件，在 Git 内都只有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地数据库 中了；已修改表示修改了某个文件，但还没有提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中。由此我们看到 Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。
?????????????
????????????? 从本地分支分支维护的层面讲，图中Git本地和服务器端结构都很灵活，所有版本都存储在一个目录中，你只需要进行分支的切换即可达到在某个分支工作的效 果。而SVN则完全不同，如果你需要在本地试验一些自己的代码，只能本地维护多个不同的拷贝，每个拷贝对应一个SVN服务器地址。
????????????? 分布式对于Git而言，你可以本地提交代码，所以在上面的图中，Git有利于将一个大任务分解，进行本地的多次提交，而SVN只能在本地进行大量的一次性 更改，导致将来合并到主干上造成巨大的风险。Git的代码日志是在本地的，可以随时查看。SVN的日志在服务器上的，每次查看日志需要先从服务器上下载下 来。
????????????? Git和SVN的主要区别，归纳起来主要有以下5点：
????????????? 1）GIT是分布式的，SVN不是：
?????????????????? 这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT 并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提 交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。
?????????????? 2）GIT把内容按元数据方式存储，而SVN是按文件：
?????????????????? 所 有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很 大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。
?????????????? 3）GIT分支和SVN的分支策略不同：
?????????????????? 分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。 然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。
?????????????? 4）GIT没有一个全局的版本号，而SVN有：
?????????????????? 目前为止这是跟SVN相比GIT缺少的最大的一个特征。你肯定知道，SVN的版本号实际是任何一个相应时间的源代码快照。
?????????????? 5）GIT的内容完整性要优于SVN：
?????????????????? GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。
??? 如何理解Git的分布式 & 我们为什么要用Git????????????? 去中心化：去中心化绝对是Git最伟大的改变，每个人机器上都是一个完整的库， 我们平时开发代码时的中央服务器其实和我们自己机器上的库内容是完全一样的（格式有点不同，是bare的）。虽然平时大家 都是将代码提交到中央服务器上再统一pull别人的代码，但实际情况你可以总是pull张三的库，然后push给李四等等操作。如果你用过Github， 你肯定知道大名鼎鼎的fork功能，你可以fork任何一个你喜欢的项目，接着按自己的喜好修改成自己的项目，或是发起pull request请原作者merge你的功能到他们项目里去（这同样也得益于Git另一项与SVN很大不同的功能------上面提到的第3小点：分支策 略），而且大多数开源项目都会鼓励你去fork它们。这里面没有权威，没有主从。
????????????? 离线提交：本地的离线提交好处主要有以下几个：
?????????????????? 1）断网提交。不要认为这个没用，想想上面提到的例子：在火车飞机或是脱离网络需要工作的情况。
?????????????????? 2）小步提交。可以对自己的阶段成果有跟踪，并且提高每次变更的安全性。
?????????????????? 3）本地库。这个和断网提交是同一个实现，但从需求角度出发则略有不同，主要是说即使只有自己一个人开发项目，也可以轻易的让自己的代码有版本跟踪，而不需要去费力建个什么svn server。
?????????????????? 4）本地回滚。这个其实是由于本地库的存在而产生的，但可以减少中央库上的冗余版本。
????????????? 分支策略：分支策略从技术上来讲是将版本节点化了，即最终的版本状态是树状的。从结果上来讲既是弱化了分支，也是强化了分支。弱化的是分支的概念，强化的是分支的功能。分之策略是Git最强大的功能，没有之一。请大家日后慢慢体会。
????????????? 当然，Git其实还有很多其他的有点，大家用熟悉了以后就自然和SVN有一个比较鲜明的对比了。
2. Git基础命令及演示：??? 首次运行Git前的配置：????????????? -> /etc/gitconfig文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项，读写的就是这个文件。
????????????? -> ~/.gitconfig 文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项，读写的就是这个文件。
????????????? -> 当前项目的 git 目录中的配置文件（也就是工作目录中的 .git/config 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。
????????????? -> 在 Windows 系统上，Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录，一般都是 C:\Documents and Settings\$USER。此外，Git 还会尝试找寻 /etc/gitconfig 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。
????????????? 必要配置：你个人的用户名称和电子邮件地址，以及编辑器。这两条配置很重要，每次 Git 提交时都会引用这两条信息，说明是谁提交了更新，所以会随更新内容一起被永久纳入历史记录：
??? 开发分支develop：????????????? 主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
????????????? 这里顺便给大家讲一下Git合并过程中的FF模式和Normal模式，默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。FF模式使用的命令是：
????????????? --no-ff: http://gitlab.alibaba-inc.com/xiaopan.baoxp/bobtest/network/master
????????????? normal: http://gitlab.alibaba-inc.com/xiaopan.baoxp/releasecenter/network/master
??? 临时性分支：功能（feature）分支、预发布（release）分支、修复（hotfix）分支：????????????? 前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：功能（feature）分支、预发布（release）分支、修复（hotfix）分支。这三种分支都属于临时性需要，使用完以后，应该删除（这和svn有很大的区别，svn是不鼓励甚至是禁止进行删除操作的），使得代码库的常设分支始终只有Master和Develop。
????????????? 功能分支：从Develop分支上面分出来，开发完成后，要再并入Develop????????????? 预发布分支：是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。4. Git的权限控制：??? 我们公司用的是Gitlab，所以这里就针对Gitlab的权限控制进行一个简要的说明，Gitlab中对权限的分配大致有2中情况：
??? 1）用户授权：
???????? 添加仓库的新成员：
???????? 在一个仓库的首页可以看到如下的一个操作区
???????? 选择 Team 标签，会列出当前的仓库的所有成员
???????? 点击 就可以添加新的仓库成员
???????? 在新的添加用户的界面中（如下）可以选择要添加的新用户的名字，用户的角色( 包括 guest,reporter,developer,master )
???????? 选择好对应的角色名称和对应的权限之后就可以点击保存了，这样就添加了一个团队的成员。
???????? 仓库成员的权限介绍：* Guest:
创建一条issue进行代码的评论在项目强上面留言Reporter:包括所有 Guest 的权限拉取项目的代码下载项目代码创建一个 merge 请求创建一个代码片段Developer:包括所有 Reporter 的权限创建新分支向非受保护分支推送代码删除非受保护分支添加 tags编辑项目的 wikiMaster:包括所有 Developer 的权限添加新的团队的成员向受保护分支推送代码删除受保护的分支使用“强制”选项进行推送编辑项目添加项目的只读授权 key配置项目Git Hooks??? 2）密钥授权：
???????? 在你的个人profile页面：http://gitlab.alibaba-inc.com/profile，可以添加ssh key，在添加了ssh key之后，你所在的机器就可以访问你所拥有权限的任何项目了：
???????? 添加key时请慎重，因为这意味着所有能访问这台机器的人都可以对你的项目进行操作，一般对于开发人员来说，都会给自己的开发机加上key。
???????? 除此以外，还需要注意，一个key只能加一次，再次添加就会出错，举个例子：我在我的配置里添加了A机器的key，然后风伯想要在他的配置里加上A的key，就会失败。
5. Git中的MarkDown说明文件介绍：? ? 使用MarkDown语法的README文件????????????? 在Github中的项目主页里，我们经常可以看到一个README.md文件，这个文件就是使用markdown语法编写的说明文件，添加合适的README文件是一个很好的习惯。这里具体的语法就不做介绍了，请自行参看上面的链接。另外，还有很多的在线编辑器，如以下两个：http://dillinger.io/， http://markable.in/editor/
6. 定制自己的Git：??? 配置 .gitconfig：这一内容已经在第2点中的第一小点中做过说明，这里不再做重复说明，举例一些常用的缩写，如： 图片看不了啊