关于Git及其基础应用

归于”关于Git“这一分类下的一系列心得或者随笔，很大一部分得益于Scott Chacon的《Pro Git》，鉴于读罢此书时日不久，称作读书笔记也未尝不可以。现学现卖，抛砖引玉。
Git，作为版本控制系统，常常受人忽视。而现实是，一些简单、基础的调用就可以满足大多数的需要。这篇博客即将介绍的基础Git 命令就能是如此，即使不再深入学习Git，使用这些命令也能满足大多数的需要。命令部分请移步

版本控制系统：简述

中心化版本控制系统(Centralized Version Control System)与分布式版本控制系统(Distributed Version Control System)，是当下主流的两种版本控制系统，前者的代表有：CVS，Preforce，SCN；而后者的有Git与Mercurial。两者的主要区别在于，中心化的版本控制系统将文件修改的历史记录保存在一个中心服务器，用户通过向服务器发送请求，取得或者上传最新的改动。这样一来，所有服务端的资料都能共享。分布式则更进一步，每位用户都有一份本地的版本记录，其中涵括了不同版本的文件和修改记录；本地的版本记录来自一个中心集合（服务器），共享该集合的用户可以互相同步文件与记录。因为Git采取了这种设计，即使中心服务器崩溃，也不会造成恶劣的影响；另一方面，其实失去网络连接，Git用户也能照常工作，在这一系统中，几乎所有的操作都是本地的。

关于GIT

附于主题，我们将讨论重点转向Git。简单来说，Git 在工作时有三个状态，committed（已确认并发布）, modified（已修改）, staged（已置入下一次发布的集合中）。当处于committed状态时，数据已经安全地存入本地的数据库中；当用户编辑了文件并且没有进行commit 操作时，Git 将显示modified 状态；Staging 则作为数据入仓前的状态，如果一个修改过的文件被列入下一次commit的清单里，Git 将显示staged状态。举个例子，我的团队正在写作一个RPG 游戏，现已完成基本功能健全的版本1.0，有天我突发奇想要屠龙刀和一刀999级，改写了代码 -> modified，但我不想当下发布这一更新，比如我发现了一些需要改正的bug，那么我先将这些编辑过的代码标记到下一次更新的列表里 -> staged，某一天我终于完成了所有工作，此时我进行commit操作 -> committed ->探晚揽月。通过前文非常业余的介绍，一些概念也许难以理解，那么，Git 工作流程了解一下。



在上图中，”git directory（Repository）系Git系统存储工程项目的元数据（metadata）及其对象数据库（object database）的分支目录“（翻译自https://git-scm.com/book/en/v2/Getting-Started-Git-Basics，图片也采自相同的网页），看起来不仅难懂，而且拗口，简单说这就是从中心集（服务器）合拷贝的最新版本文件。
”工作目录(working Directory) 系项目单一版本的总结（checkout)"，可以参照机翻，正在工作的目录，就是当下处于用户磁盘中的，本地的文件，这些文件都由上文中的git directory 中取得。处于本地和git directory之间，“集合缓存区（Staging Area）一般是一个文件，该文件记录下一次要commit 的内容，在一些情况下，这个文件也被称为index，但出于标准化的考虑，我们现在称之为Staging Area”。在《Pro Git》一书中，提到了snapshot 的概念，这是指Git 系统对整个工程项目进行快照，首先Git 将项目当作一系列的迷你文件系统，每一次用户使用commit 命令时，都将生成一副快照（snapshot），并将这副快照存入本地的Git 系统里。在Staging 的过程中，Stage Area 会储存标记为Staged 文件的快照。
结合上图引入的概念，总结Git的工作流如下：
    1.修改工作目录（Working Directory）下的文件。
    2.集合工作目录下编辑过的文件，在Stage Area 文件内写入一个快照（snapshot）。

    3.通过检查Stage Area 确认并发布这些新版本的文件，先前写入Stage Area 的快照将被存入Git 系统，以备日后需要。

使用GIT

安装GIT

在这个网页，有关于如何安装Git 的详细描述，https://git-scm.com/book/en/v2/Getting-Started-Installing-Git。