分布式版本控制Git基本用法详解
一、git的初始化
1.Git 配置
使用Git的第一件事就是设置你的名字和email,这些就是你在提交commit时的签名。
$ git config --global user.name "Scott Chacon"
$ git config --global user.email "schacon@gmail.com"
执行了上面的命令后,会在家目录(/home)下建立一个叫.gitconfig 的文件（该文件问隐藏文件，需要使用ls -al查看到）. 内容一般像下面这样，可以使用vim或cat查看文件内容:
$ cat ~/.gitconfig
[user]
name = Scott Chacon
email = schacon@gmail.com
如果你想使项目里的某个值与前面的全局设置有区别(例如把私人邮箱地址改为工作邮箱);你可以在项目中使用git config 命令不带 --global 选项来设置. 这会在你项目目录下的 .git/config 文件增加一节[user]内容(如上所示)。对于新建项目，这部分定制操作需要在git初始化之后才可以执行.
二、获得一个Git仓库
既然我们现在把一切都设置好了，那么我们需要一个Git仓库。有两种方法可以得到它：一种是从已有的Git仓库中clone (克隆，复制)；还有一种是新建一个仓库，把未进行版本控制的文件进行版本控制。
1.Clone一个仓库
为了得一个项目的拷贝(copy),我们需要知道这个项目仓库的地址(Git URL). Git能在许多协议下使用，所以Git URL可能以ssh://, http(s)://, git://,或是只是以一个用户名（git 会认为这是一个ssh 地址）为前辍. 有些仓库可以通过不只一种协议来访问，例如，Git本身的源代码你既可以用 git:// 协议来访问：
$ git clone http://git.shiyanlou.com/shiyanlou/gitproject
也可以通过http 协议来访问:
$ git clone http://github.com/shiyanlou/gitproject.git
当前git project仅是测试项目，里面仅有一个README.md文件
2.初始化一个新的仓库
可以对一个已存在的文件夹用下面的命令让它置于Git的版本控制管理之下. 创建文件夹
$ mkdir project
添加文件及文件内容
$ echo "test content" > project/testfile.txt
Git仓库初始化
$ cd project
$ git init
Git会输出:
Initialized empty Git repository in /home/shiyanlou/project/.git/
通过la命令会发现project目录下会有一个名叫”.git” 的目录被创建，这意味着一个仓库被初始化了。
三、正常的工作流程
1.正常的工作流程
进入我们刚才建立的project目录，创建文件file1，file2，file3
$ cd project
$ touch file1 file2 file3
修改文件，可以使用vim编辑内容，也可以直接echo添加测试内容。将它们更新的内容添加到索引中.
$ echo "testcontent1" >> file1
$ echo "testcontent2" >> file2
$ echo "testcontent3" >> file3
$ git add file1 file2 file3
你现在为commit做好了准备，你可以使用 git diff 命令再加上 --cached 参数 ,看看哪些文件将被提交(commit)。
$ git diff --cached
(如果没有--cached参数，git diff 会显示当前你所有已做的但没有加入到索引里的修改.) 你也可以用git status命令来获得当前项目的一个状况:
$ git status
如果你要做进一步的修改, 那就继续做, 做完后就把新修改的文件加入到索引中. 最后把他们提交：
$ git commit -m "put a message to commit"
需要使用-m添加本次修改的注释，完成后就会记录一个新的项目版本.除了用git add 命令，我们还可以用
$ git commit -a -m "put a message to commit"
这会自动把所有内容被修改的文件(不包括新创建的文件)都添加到索引中，并且同时把它们提交。
四、分支与合并
1.分支
一个Git仓库可以维护很多开发分支。现在我们来创建一个新的叫 experimental的分支
$ git branch experimental
如果你运行下面这条命令：
$ git branch
你会得到当前仓库中存在的所有分支列表：
experimental
* master
experimental 分支是你刚才创建的，master分支是Git系统默认创建的主分支。星号(“*”)标识了你当工作在哪个分支下，输入：
$ git checkout experimental
切换到”experimental”分支，先编辑里面的一个文件，再提交(commit)改动，最后切换回 “master”分支。
$ git commit -a -m "put a message to commit"
$ git checkout master
你现在可以看一下你原来在“experimental”分支下所作的修改还在不在；因为你现在切换回了“master”分支，所以原来那些修改就不存在了。 你现在可以在“master”分支下再作一些不同的修改:
$ git commit -a -m "put a message to commit"
这时，两个分支就有了各自不同的修改(diverged)；我们可以通过下面的命令来合并“experimental”和“master”两个分支:
$ git merge experimental
如果这个两个分支间的修改没有冲突(conflict), 那么合并就完成了。如果有冲突，输入下面的命令就可以查看当前有哪些文件产生了冲突:
$ git diff
当你编辑了有冲突的文件，解决了冲突后就可以提交了：
$ git commit -a -m "put a message to commit"
这时你就可以删除掉你的 “experimental” 分支了(如果愿意)：
$ git branch -d experimental
git branch -d只能删除那些已经被当前分支的合并的分支. 如果你要强制删除某个分支的话就用git branch ?D；下面假设你要强制删除一个叫”crazy-idea”的分支：
$ git branch -D crazy-idea
2.解决合并中的冲突
如果执行自动合并没有成功的话，git会在索引和工作树里设置一个特殊的状态， 提示你如何解决合并中出现的冲突。 有冲突(conflicts)的文件会保存在索引中，除非你解决了问题并且更新了索引，否则执行 git commit都会失败 如果执行 git status 会显示这些文件没有合并(unmerged),这些有冲突的文件里面会添加像下面的冲突标识符:
<<<<<<< HEAD:file.txt
Hello world
=======
Goodbye
>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
你所需要的做是就是编辑解决冲突，（接着把冲突标识符删掉），再执行下面的命令:
$ git add file.txt
$ git commit -m "put a message to commit"
3.撒销一个合并
如果你觉得你合并后的状态是一团乱麻，想把当前的修改都放弃，你可以用下面的命令回到合并之前的状态：
$ git reset --hard HEAD
或者你已经把合并后的代码提交，但还是想把它们撒销：
$ git reset --hard ORIG_HEAD
但是刚才这条命令在某些情况会很危险，如果你把一个已经被另一个分支合并的分支给删了，那么以后在合并相关的分支时会出错
4.快速向前合并
还有一种需要特殊对待的情况，在前面没有提到。通常，一个合并会产生一个合并提交(commit), 把两个父分支里的每一行内容都合并进来。 但是，如果当前的分支和另一个分支没有内容上的差异，就是说当前分支的每一个提交(commit)都已经存在另一个分支里了，git 就会执行一个“快速向前"(fast forward)操作；git 不创建任何新的提交(commit),只是将当前分支指向合并进来的分支。
五、Git日志
1.查看日志
git log命令可以显示所有的提交(commit) 当然你也可以组合上面的命令选项；下面的命令就是找出所有从"v2.5“开始在fs目录下的所有Makefile的修改.
$ git log v2.5.. Makefile fs/
Git会根据git log命令的参数，按时间顺序显示相关的提交(commit)。
2.日志统计
如果用--stat选项使用'git log',它会显示在每个提交(commit)中哪些文件被修改了, 这些文件分别添加或删除了多少行内容.
$ git log --stat
3.格式化日志
你可以按你的要求来格式化日志输出。‘--pretty'参数可以使用若干表现格式，如‘oneline':
$ git log --pretty=oneline
或者你也可以使用 'short' 格式:
$ git log --pretty=short
你也可用‘medium','full','fuller','email' 或‘raw'. 如果这些格式不完全符合你的相求， 你也可以用‘--pretty=format'参数 另一个有趣的事是：你可以用'--graph'选项来可视化你的提交图(commit graph),它会用ASCII字符来画出一个很漂亮的提交历史(commit history)线。
4.日志排序
你也可以把日志记录按一些不同的顺序来显示。注意，git日志从最近的提交(commit)开始，并且从这里开始向它们父分支回溯。然而git历史可能包括多个互不关联的开发线路，这样有时提交(commits)显示出来就有点杂乱。 如果你要指定一个特定的顺序，可以为git log命令添加顺序参数(ordering option). 按默认情况，提交(commits)会按逆时间(reverse chronological)顺序显示。 但是你也可以指定‘--topo-order'参数，这就会让提交(commits)按拓扑顺序来显示(就是子提交在它们的父提交前显示). 如果你用git log命令按拓扑顺序来显示git仓库的提交日志，你会看到“开发线"(development lines)都会集合在一起.
$ git log --pretty=format:'%h : %s' --topo-order --graph
你也可以用'--date-order'参数，这样显示提交日志的顺序主要按提交日期来排序. 这个参数和'--topo-order'有一点像，没有父分支会在它们的子分支前显示，但是其它的东东还是按照时间来排序显示。你会看到"开发线"(development lines)没有集合一起，它们会像并行开发(parallel development)一样跳来跳去的：
$ git log --pretty=format:'%h : %s' --date-order --graph
你也可以用 ‘--reverse'参数来逆向显示所有日志。
六、比较提交 - Git Diff
1.比较提交 - Git Diff
你可以用 git diff 来比较项目中任意两个版本的差异。
$ git diff master..test
上面这条命令只显示两个分支间的差异，如果你想找出‘master’,‘test’的共有父分支和'test'分支之间的差异，你用3个'.'来取代前面的两个'.' 。
$ git diff master...test
git diff 是一个难以置信的有用的工具，可以找出你项目上任意两点间 的改动，或是用来查看别人提交进来的新分支。
2.哪些内容会被提交(commit)
你通常用git diff来找你当前工作目录和上次提交与本地索引间的差异。
$ git diff
上面的命令会显示在当前的工作目录里的，没有 staged(添加到索引中)，且在下次提交时不会被提交的修改。 如果你要看在下次提交时要提交的内容(staged,添加到索引中),你可以运行：
$ git diff HEAD
上面这条命令会显示你工作目录与上次提交时之间的所有差别，这条命令所显示的内容都会在执行"git commit -a"命令时被提交。
3.更多的比较选项
如果你要查看当前的工作目录与另外一个分支的差别，你可以用下面的命令执行:
$ git diff test
这会显示你当前工作目录与另外一个叫'test'分支的差别。你也以加上路径限定符，来只比较某一个文件或目录。
$ git diff HEAD -- ./lib
上面这条命令会显示你当前工作目录下的lib目录与上次提交之间的差别(或者更准确的 说是在当前分支)。 如果不是查看每个文件的详细差别，而是统计一下有哪些文件被改动，有多少行被改 动，就可以使用‘--stat' 参数。
$ git diff --stat
有时这样全局性的查看哪些文件被修改，能让你更轻一点。
七、分布式的工作流程
1.分布式的工作流程
现在我们的项目在/home/shiyanlou/gitproject建了一个新的git 仓库(repository)；另一个用户的工作目录也在同一台机器，也要提交代码。 执行了这样的命令克隆新的工作目录
$ git clone /home/shiyanlou/gitproject myrepo
这就建了一个新的叫"myrepo"的目录，这个目录里包含了一份gitproject仓库的克隆(clone). 这份克隆和原始的项目一模一样，并且拥有原始项目的历史记录。 在myrepo做了一些修改并且提交(commit)它们:
$ cd myrepo
$ echo "newcontent" > newfile
$ git add newfile
$ git commit -m "add"
myrepo修改完成后，需要在仓库/home/shiyanlou/gitproject中把myrepo的修改给拉 (pull)下来。执行下面几条命令:
$ cd /home/shiyanlou/gitproject
$ git pull /home/shiyanlou/myrepo master
这就把myrepo的主(master)分支合并到了gitproject的当前分支里了。如果gitproject在myrepo修改文件内容的同时也做了修改的话，他可能需要手工去修复冲突. (注意："master"参数在上面的命令中并不一定是必须的，因为这是一个 默认参数) git pull命令执行两个操作: 它从远程分支(remote branch)抓取修改 的内容，然后把它合并进当前的分支。 如果你要经常操作远程分支(remote branch),你可以定义它们的缩写:
$ git remote add myrepo /home/shiyanlou/myrepo
这样，gitproject里可以用"git fetch"" 来执行"git pull"前半部分的工作， 但是这条命令并不会把抓下来的修改合并到当前分支里。
$ git fetch myrepo
我们用git remote命令建立了myrepo的远程仓库的缩写，用这个(缩写) 名字我从myrepo那得到所有远程分支的历史记录。在这里远程分支的名 字就叫myrepo/master.
$ git log -p master..myrepo/master
上面的命令把myrepo从gitproject的主分支(master)中签出后所做的修改全部显示出来。 当检查完修改后,gitproject就可以把修改合并到它的主分支中。
$ git merge myrepo/master
这种合并(merge)也可以用pull来完成，就像下面的命令一样：
$ git pull . remotes/myrepo/master
注意：git pull 会把远程分支合并进当前的分支里，而不管你在命令行里指定什么。 其后，myrepo可以更新它的本地仓库--把gitproject做的修改拉过来(pull):
$ git pull
如果myrepo从gitproject的仓库克隆(clone)，那么他就不需要指定gitproject仓库的地 址；因为Git把gitproject仓库的地址存储到myrepo的仓库配库文件，这个地址就是在git pull时使用：
$ git config --get remote.origin.url
Git同时也保存了一份最初(pristine)的gitproject主分支(master),在origin/master下面。
$ git branch -r
如果myrepo打算在另外一台主机上工作，他可以通过ssh协议来执行"clone" 和"pull"操作：
$ git clone alice.org:/home/shiyanlou/gitproject myrepo
2.公共Git仓库
另外一个提交修改的办法，就是告诉项目的维护者(maintainer)用 git pull 命令从你的仓库里把修改拉下来。这和从主仓库"里更新代码类似，但是是从 另外一个方向来更新的。 如果你和维护者(maintainer)都在同一台机器上有帐号，那么你们可以互相从对 方的仓库目录里直接拉(pull)所作的修改；git命令里的仓库地址也可以是本地 的某个目录名：
$ git clone /path/to/repository
$ git pull /path/to/other/repository
也可以是一个ssh地址：
$ git clone ssh://yourhost/~you/repository
3.将修改推到一个公共仓库
通过http或是git协议，其它维护者可以抓取(fetch)你最近的修改，但是他们 没有写权限。这样，这需要将本地私有仓库的最近修改上传公共仓库中。 译者注: 通过http的WebDav协议是可以有写权限的,也有人配置了git over http. 最简单的办法就是用 git push命令 和ssh协议; 用你本地的"master" 分支去更新远程的"master"分支，执行下面的命令:
$ git push ssh://yourserver.com/~you/proj.git master:master
或者
$ git push ssh://yourserver.com/~you/proj.git master
和git-fetch命令一样git-push如果命令的执行结果不是"快速向前"(fast forward) 就会报错; 下面的章节会讲如何处理这种情况。 推(push)命令的目地仓库一般是个裸仓库(bare respository)。 你也可以推到一 个签出工作目录树(checked-out working tree)的仓库，但是工作目录中内 容不会被推命令所更新。如果你把自己的分支推到一个已签出的分支里，这 会导致不可预知的后果。 在用git-fetch命令时，你也可以修改配置参数，让你少打字。 下面这些是例子:
$ cat >>.git/config <<EOF
你可以用下面的命令来代替前面复杂的命令:
$ git push public-repo master
4.当推送代码失败时要怎么办
如果推送(push)结果不是"快速向前"(fast forward),那么它可能会报像下面一样的错误：
error: remote 'refs/heads/master' is not an ancestor of
local 'refs/heads/master'.
Maybe you are not up-to-date and need to pull first?
error: failed to push to 'ssh://yourserver.com/~you/proj.git'
这种情况通常由以下的原因产生： 用 git-reset --hard删除了一个已经发布了的一个提交，或是 用 git-commit --amend 去替换一个已经发布的提交，或是 用 git-rebase 去rebase一个已经发布的提交. 你可以强制git-push在上传修改时先更新，只要在分支名前面加一个加号。
$ git push ssh://yourserver.com/~you/proj.git +master
八、Git标签
1.轻量级标签
我们可以用 git tag不带任何参数创建一个标签(tag)指定某个提交(commit):
$ git tag stable-1 1b2e1d63ff
这样，我们可以用stable-1 作为提交(commit) "1b2e1d63ff" 的代称(refer)。 前面这样创建的是一个“轻量级标签"，这种分支通常是从来不移动的。 如果你想为一个标签(tag)添加注释，或是为它添加一个签名(sign it cryptographically), 那么我们就需要创建一个 "标签对象"。
标签对象
如果有 "-a", "-s" 或是 "-u " 中间的一个命令参数被指定，那么就会创建一个标签对象，并且需要一个标签消息(tag message). 如果没有"-m " 或是 "-F " 这些参数，那么就会启动一个编辑器来让用户输入标签消息(tag message).。 当这样的一条命令执行后，一个新的对象被添加到Git对象库中，并且标签引用就指向了一个标签对象，而不是指向一个提交(commit). 这样做的好处就是：你可以为一个标签到处签名(sign), 方便你以后来查验这是不是一个正确的提交(commit). 下面是一个创建标签对象的例子:
$ git tag -a stable-1 1b2e1d63ff
标签对象可以指向任何对象，但是在通常情况下是一个提交(commit). (在Linux内核代码中，第一个标签对象是指向一个树对象(tree),而不是指向一个提交(commit))。
2.签名的标签
如果你配有GPG key,那么你就很容易创建签名的标签。首先你要在你的 .git/config 或 ~/.gitconfig里配好key。 下面是示例:
[user]
signingkey = <gpg-key-id>
你也可以用命令行来配置:
$ git config (--global) user.signingkey <gpg-key-id>
现在你可以直接用"-s" 参数来创建“签名的标签”。
$ git tag -s stable-1 1b2e1d63ff
如果没有在配置文件中配GPG key,你可以用"-u“ 参数直接指定。
$ git tag -u <gpg-key-id> stable-1 1b2e1d63ff
九、小结
git config：配置相关信息；git clone：复制仓库；git init：初始化仓库；git add：添加更新内容到索引中；git diff：比较内容；git status：获取当前项目状况；git commit：提交；git branch：分支相关；git checkout：切换分支；git merge：合并分支；git reset：恢复版本；git log：查看日志；比较提交使用git diff；分布式的工作流程；标签使用git tag命令。
