目录
- Git 笔记系列（一）—— Git简介
- Git 笔记系列（二）—— Git工作流程
- Git 笔记系列（三）—— Git常用命令
- Git 笔记系列（四）—— Git常用命令-Branch
- Git 笔记系列（五）—— Git常用命令-Stash等
- Git 笔记系列（六）—— Git常用命令-Rebase
- Git 笔记系列（七）—— Git常用命令-Fork
- Git 笔记系列（八）—— Git进阶
- Git 笔记系列（九）—— Git常见问题
- Git 笔记系列（十）—— Git进阶, 巧用Git工具
- Git 笔记系列（十一）—— Git进阶, Git的奇技赢巧
引言
Git很多开发团队在使用，但是Git很多强大的特性不一定都很了解，基于以前的使用以及参考Git的博客，将用一系列文章介绍Git, 从原理到常用命令，希望能更好的使用Git, 提高团队开发效率。
关于版本控制
什么是“版本控制”？我为什么要关心它呢？ 版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 一般是对软件源代码的文件作版本控制，但实际上，你可以对任何类型的文件进行版本控制。
版本控制的软件和设计模式有很多，但是，你来阅读这Git这一系列文章我相信至少是对Git产生了兴趣，那就不妨点击阅读全文，进来坐坐。
集中化管理系统
Centralized Version Control Systems，简称 CVCS， 这类系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。 多年以来，这已成为版本控制系统的标准做法。它的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。
image
评价：这种方式解决了版本控制问题，但是过于依赖中央服务器——Central VCS Server，如果中央服务器出现问题，将不可以再提交代码，如果数据未备份，无法恢复，则丢失所有的数据，文件和log提交记录，而且本地只是保存一个版本的快照，从而只剩下各个用户的本地快照记录。
分布式版本控制系统
Distributed Version Control System，简称DVCS， 在这类系统中，代表的有 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
image
简介
So, what hell is Git?
How to use git😄
Git的历史
Git是由Linux的缔造者Linus Torvalds，在2005年基于使用BitKeeper时的经验教训，开发出自己的版本系统。
Git的目标：
- 速度
- 简单的设计
- 对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
- 完全分布式
- 有能力高效管理类似
Linux内核一样的超大规模项目（速度和数据量）
Git 作为现在最流行的开源的版本控制系统,了SVN的一些特性（tag, branch），采用了巧妙的设计(本地库)，让并行开发更高效。 可以说Git是目前用户最多，最火的版本控制系统。
Git的优点
- 客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。
- 可以指定和若干不同的远端代码仓库进行交互，就可以在同一个项目中，分别和不同工作小组的人相互协作（
Git强大的分支功能）。 你可以根据需要设定不同的协作流程，而在集中式系统中是无法实现的。 - 近乎所有操作都是本地执行, 在
Git中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。 因为你在本地磁盘上就有项目的完整历史，所以大部分操作看起来瞬间完成。 -
Git保证完整性，Git中所有数据在存储前都计算校验和，然后以校验和来引用。 这意味着不可能在Git不知情时更改任何文件内容或目录内容。 若你在传送过程中丢失信息或损坏文件，Git就能发现。
Git的工作原理
处理数据的方式
Git 和其它版本控制系统（包括Subversion和近似工具）的主要差别在于 Git 对待数据的方法。
-
SVN——以文件变更列表的方式存储信息。
将保存的信息看作是一组文件+文件随时间累积的差异。
image
-
Git——直接记录快照，而非差异比较
每次你提交更新，或在 Git 中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个快照流。
image
这是 Git 与几乎所有其它版本控制系统的重要区别, Git 分支管理时，将探究这种方式对待数据所能获得的益处。
Git的计算校验和的机制
Git 中所有数据在存储前都计算校验和，然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 若你在传送过程中丢失信息或损坏文件，Git 就能发现。
Git 用以计算校验和的机制叫做SHA-1 散列（hash，哈希）。 这是一个由 40 个十六进制字符（0-9 和 a-f）组成字符串，基于 Git 中文件的内容或目录结构计算出来。 SHA-1哈希看起来是这样：
24b9da6552252987aa493b52f8696cd6d3b00373
为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了。
Git 中使用这种哈希值的情况很多，你将经常看到这种哈希值。 实际上，Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。
Git 一般只添加数据
你执行的 Git 操作，几乎只往 Git 数据库中增加数据。 很难让 Git 执行任何不可逆操作，或者让它以任何方式清除数据。
Git的工作流程
Git的三个工作区域
Git 有三种状态，你的文件可能处于其中之一：
- 已修改（
modified）： 修改了文件，但还没保存到数据库中。 - 已暂存（
staged） ：对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。 - 已提交（
committed）：数据已经安全的保存在本地数据库中
由此引入 Git 项目的的概念：Git 仓库、工作目录以及暂存区域。一个Git项目可以被看做一下三个部分：
image
-
Working Directory: 工作目录是对项目的某个版本独立提取出来的内容。 这些从
Git仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改。你将在里面完成文件的创建、编辑、删除、整理的所有工作。 -
Staging Area: 暂存区域是一个文件，保存了下次将提交的文件列表信息，一般在
Git仓库目录中。 有时候也被称作`‘索引’'，不过一般说法还是叫暂存区域，列出对工作目录所做的更改。 -
Repository:
Git仓库是Git用来保存项目的元数据和对象数据库的地方。Git永久的保存着这个项目版本间的不同变化。这是 Git 中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据。
基本的 Git 工作流程如下：
- 在工作目录中修改文件。
- 暂存文件，将文件的快照放入暂存区域。
- 提交更新，找到暂存区域的文件，将快照永久性存储到
Git仓库目录。
image
Where to Go Next
读完这篇相信你对 Git 有了更初步的理解，那么具体在开发中，如何使用用Git来完成版本控制，可以在下篇Git 笔记系列（二）—— Git工作流程得到回答，第二篇将会对 Git 的工作流和常用命令进行简单介绍。
参考
- Setting up a repository | Atlassian Git Tutorial
- Git-recipes 高质量的Git中文教程，Atlassian Git Tutorial的翻译
- Git - 关于版本控制
- Git-flow 备忘清单
- Beginning Git | Ray Wenderlich
- New Course: Mastering Git | Ray Wenderlich
网友评论