Git 配置和创建项目
Git配置
git config命令允许你在命令行中配置你的Git安装（或是一个独立仓库）。这个命令定义了所有配置，从用户信息到仓库行为等等。一些常见的配置命令如下所列。
用法
git config user.name <name>
定义当前仓库所有提交使用的作者姓名。通常来说，你希望使用--global标记设置当前用户的配置项。 sh git config --global user.name <name> 定义当前用户所有提交使用的作者姓名。 sh git config --global user.email <email> 定义当前用户所有提交使用的作者邮箱。 sh git config --global alias.<alias-name> <git-command> 为Git命令创建一个快捷方式（别名）。 sh git config --system core.editor <editor> 定义当前机器所有用户使用命令时用到的文本编辑器，如git commit。<editor>参数用编辑器的启动命令（如vi）替代。 sh git config --global --edit 用文本编辑器打开全局配置文件，手动编辑。 #### 最佳实践和例子
所有配置项都储存在纯文本文件中，所以git config命令其实只是一个提供便捷的命令行接口。通常，你只需要在新机器上配置一次Git安装，以及，你通常会想要使用--global标记。
Git将配置项保存在三个单独的文件中，允许你分别对单个仓库、用户和整个系统设置。 -
[user]
name = John Smith
email = john@example.com
[alias]
st = status
co = checkout
br = branch
up = rebase
ci = commit
[core]
editor = vim
你可以用git config手动编辑这些值。
Git 初始化
git init命令创建一个新的Git仓库。它用来将已存在但还没有版本控制的项目转换成一个Git仓库，或者创建一个空的新仓库。大多数Git命令在未初始化的仓库中都是无法使用的，所以这就是你运行新项目的第一个命令了。
运行git init命令会在你项目的根目录下创建一个新的.git目录，其中包含了你项目必需的所有元数据。除了.git目录之外，已经存在的项目不会被改变（就像SVN一样，Git不强制每个子目录中都有一个.git目录）。
用法
git init
将当前的目录转换成一个Git仓库。它在当前的目录下增加了一个.git文件夹，于是就可以开始记录项目版本了。 shell git init <directory> 在指定目录创建一个空的Git仓库。运行这个命令会创建一个名为directory，只包含.git子目录的空文件夹。 shell git init --bare <directory> 初始化一个裸的Git仓库，但是忽略工作目录。共享的仓库应该总是用--bare标记创建（见下面的讨论）。一般来说，用—bare标记初始化的仓库以.git结尾。比如，一个叫my-project的仓库，它的空版本应该保存在my-project.git目录下。
最佳实践与例子
和SVN相比，git init命令是一个创建新的版本控制项目非常简单的途径。Git不需要你创建仓库，导入文件，检查正在修改的拷贝。你只需要cd到你的项目目录下，运行git init，你就有了一个功能强大的Git仓库。
但是，对大多数项目来说，git init只需要在创建中央仓库时执行一次——开发者通常不会使用git init来创建他们的本地仓库。他们往往使用git clone来将已存在的仓库拷贝到他们的机器中去。
拓展：裸仓库
—bare标记创建了一个没有工作目录的仓库，这样我们在仓库中更改文件并且提交了。中央仓库应该总是创建成裸仓库，因为向非裸仓库推送分支有可能会覆盖已有的代码变动。将—bare看成是用来将仓库标记为储存设施，而不是一个开发环境。也就是说，对于所有的Git工作流，中央仓库是裸仓库，开发者的本地仓库是非裸仓库。
因为git clone创建项目的本地拷贝更为方便，git init最常见的使用情景就是用于创建中央仓库：
ssh <user>@<host>
cd path/above/repo
git init --bare my-project.git
首先，你用SSH连入存放中央仓库的服务器。然后，来到任何你想存放项目的地方，最后，使用—bare标记来创建一个中央存储仓库。开发者会将my-project.git 克隆到本地的开发环境中。
Git 克隆
git clone命令拷贝整个Git仓库。这个命令就像svn checkout一样，除了”工作副本“是一个完备的Git仓库——它包含自己的历史，管理自己的文件，以及环境和原仓库完全隔离。
为了方便起见，clone自动创建了一个名为origin的远程连接，指向原有仓库。这让和中央仓库之间的交互更加简单。
用法
git clone <repo>
将位于<repo>的仓库克隆到本地机器。原仓库可以在本地文件系统中，或是通过HTTP或SSH连接的远程机器。
git clone <repo> <directory>
将位于<repo>的仓库克隆到本地机器上的<directory>文件夹。
最佳实践与例子
如果项目在远程仓库已经设置完毕，git clone是用户获取开发副本最常见的方式。和git init相似，clone通常也是一次性的操作——只要开发者获得了一份工作副本，所有版本控制操作和协作管理都是在本地仓库中完成的。
这一点很重要，你要理解Git中”工作副本“的概念和SVN仓库check out下来的”工作副本“是很不一样的。和SVN不同的是，Git不会区分工作副本和中央仓库——它们都是功能完备的Git仓库。
这就似的Git的协作和SVN截然不同。SVN依赖于中央仓库和工作副本之间的关系，而Git协作模型是基于仓库和仓库之间的交互的。相对于SVN的提交流程，你可以在Git仓库之间push或pull提交。
当然，你也完全可以给予某个特定的仓库一些特殊的含义。比如，指定某个Git仓库为中央仓库，你就可以用Git进行中央化的工作流。重点是，这是通过约定实现的，而不是写死在版本控制系统本身。
下面这个例子演示用SSH用户名john连接到example.com，获取远程服务器上中央仓库的本地副本： shell git clone ssh://john@example.com/path/to/my-project.git cd my-project # 开始工作 第一行命令在本地机器的my-project文件夹下初始化了一个新的Git仓库，并且导入了中央仓库中的文件。接下来，你cd到项目目录，开始编辑文件、缓存提交、和其它仓库交互。同时注意.git拓展名克隆时会被去除。它表明了本地副本的非裸状态。