版本控制的基本工作流程
在我们开始搞明白 Git 命令之前，你有必要先了解一下版本控制的基本流程。这本书会向你一步步地详细阐述各种不同的工作流程。但是首先还是让我们先来一起了解一下版本控制的最基本的流程。
版本控制中的最基本的模块就是 “仓库（Repository）”。
名词解释
仓库（Repository)
你可以把一个仓库想象成一个数据库，在那里你的版本控制系统存储了项目积攒的所有版本和元数据（metadata）。在 Git 中，仓库只是一个在你项目的根目录下名为 “.git” 的隐藏文件夹。你只要知道有这个文件夹存在就足够了。你没有必要也不需要去接触或是搞明白这个文件夹。
你有两种方法可以来获取一个本地仓库到你的计算机上：
- (a) 如果在本地计算机中已经存在了一个项目，但是尚未纳入版本控制系统中，你可以为这个项目初始化一个新的仓库。
- (b) 如果你需要得到一个已经纳入版本控制系统中的项目，而且它已经存放在一个远程服务器中 （比如在互联网或者是你的局域网中）。你只需要知道这个仓库的 URL 地址，然后克隆 （下载/拷贝） 到你的本地计算机中就可以了。
(1) 只要你有了一个本地仓库，你就可以在任何一个你常用的应用程序中 （例如：你最经常使用的编辑器，文件浏览器……） 开始你的工作了：修改、删除、添加、拷贝、重命名或者是移动文件。在这里你不须要考虑任何其它的事情，完成项目所要求的改动就行了。
(2) 当你已经确定完成了这次改动或者操作，你就需要开始来再次考虑版本控制了。因为是时候打包并提交你的这些改动了。
名词解释
提交（Commit）
一次提交包含了一组特定的变化。提交的作者必须为这个变化做一个简短的 "注释（commit message）"。这将有助于别人或者改动者本人在以后的时间里很好地了解和明白这次提交的意图，以及什么时间做了什么改动。
对于每组这样的更改，版本控制系统都会为你的项目缺省的创建一个新的版本。也就是说，会为每次提交创建一个单独的版本。这就是项目在这个特定时间点的快照（snapshot），版本控制系统会很有效的把这信息记录下来，而不是简单地对整个项目进行一次备份。并且提交也能非常准确的知道你的文件以及目录的状态和关系，并对它们进行有效的操作，例如：恢复项目到某些状态。
(3) 然而在提交之前，如果你需要一个到目前这个时间点的详细改动概况，那么在 Git 中，你可以使用 “status” 命令来得到一个与上一次提交对比之后的改动列表，比如哪些文件你做了改动，是否新建了一些新的文件，或者删除了一些已存在的文件。
(4) 下一步，你需要告诉 Git ，在本地项目中你想打包哪些被改动的文件到下次的提交中。一个文件被改动了之后，并不意味着它会被自动打包在下次提交中。相反，你必须明确地指出你需要打包哪些文件。这就是说你必须要把它们添加到所谓的 “暂存区（Staging Area）”。
(5) 现在，在暂存区（Staging Area）中已经存在了一些改动过的文件，现在是时间真正的提交它们了。但是在这之前你还必须为它添加一个既简短又明确的注释（commit message），用来描述这次改动到底做了什么。提交完成后本地仓库会被更新，然后为这个项目建立一个新的版本。
(6) 如果你想要查看一下整个项目的开发状况（特别是处于团队开发中），使用 "log" 命令就能看到按时间顺序列出的所有提交的改动。这时你就可以看到有哪些改动以及那些改动的一些细节，从而更好的帮助你了解你的项目的发展状况。
(7) 此外，当你处于团队协作开发时，你需要和其它的开发团队成员共享你的改动，同时也想了解其它成员所作的改动，这时一个在服务端的远程仓库（remote repository） 就可以用来进行这些数据交换。
名词解释
本地和远程仓库（Local & Remote Repositories)
两种不同的仓库类型：
- "本地" 仓库（local repository） 是放置在你的本地计算机中的，它以一个隐藏文件夹的形式存储在项目的根目录（root folder） 中。你是唯一个有权通过提交改动来操作这个仓库的用户。
- "远程" 仓库（remote" repository）则相反，它通常是位于一个远程服务器上的，比如在互联网上或在你的局域网络上。没有任何工作文件与远程仓库相关联：它没有工作目录（working directory），而是完全由 “.git”仓库目录组成的。开发团队使用远程仓库进行数据共享和交换，远程仓库是协作开发时的一个共同基础，每个项目成员都可以发布自己的改动，同样也都可以接收到其他成员的改动。
