标签：git
五、GIT分支
分支被称之为GIT最强大的特性，因为它非常地轻量级，如果用Perforce等工具应该知道，创建分支就是克隆原目录的一个完整副本，对于大型工程来说，太费时费力了，而对于GIT来说，可以在瞬间生成一个新的分支，无论工程的规模有多大，因为GIT的分支其实就是一指针而已。在了解GIT分支之前，应该先了解GIT是如何存储数据的。
前面说过，GIT存储的不是文件各个版本的差异，而是文件的每一个版本存储一个快照对象，然后通过SHA-1索引，不只是文件，包括每个提交都是一个对象并通过SHA-1索引。无论是文本文件，二进制文件还是提交，都是GIT对象。
GIT对象
每个对象(object) 包括三个部分：类型，大小和内容。大小就是指内容的大小，内容取决于对象的类型，有四种类型的对象："blob"、"tree"、 "commit" 和"tag"。
“blob”用来存储文件数据，通常是一个文件。
“tree”有点像一个目录，它管理一些“tree”或是 “blob”（就像文件和子目录）
一个“commit”指向一个"tree"，它用来标记项目某一个特定时间点的状态。它包括一些关于时间点的元数据，如提交时间、提交说明、作者、提交者、指向上次提交（commits）的指针等等。
一个“tag”是来标记某一个提交(commit) 的方法。
比如说我们执行了以下代码进行了一次提交：
$ git add README test.rb LICENSE2
$ git commit -m ‘initial commit of my project‘
现在,Git 仓库中有五个对象:三个表示文件快照内容的 blob 对象;一个记录着目录树内容及其中各个文件对应 blob 对象索引的 tree 对象;以及一个包含指向 tree 对象(根目录)的索引和其他提交信息元数据的 commit 对象。概念上来说,仓库中的各个对象保存的数据和相互关系看起来如下图：
如果进行多次提交，仓库的历史会像这样：
分支引用
所谓的GIT分支，其实就是一个指向某一个Commit对象的指针，像下面这样，有两个分支，master与testing：
而我们怎么知道当前在哪一个分支呢？其实就是很简单地使用了一个名叫HEAD的指针，如上图所示。HEAD指针的值可以为一个SHA-1值或是一个引用，看以下例子：
git的所有版本信息都保存了Working Directory下的.git目录，而HEAD指针就保存在.git目录下，如上图所有，目前为止已经有3个提交，通过查看HEAD的值可以看到我们当前在master分支：refs/heads/master，当我们通过git checkout取出某一特定提交后，HEAD的值就是成了我们checkout的提交的SHA-1值。
记录我们当前的位置很简单，就是能过HEAD指针，HEAD指向某一提交的SHA-1值或是某一分支的引用。
新建分支
git branch <branch-name>
有时需要在新建分支后直接切换到新建的分支，可以直接用checkout的-b选项
git checkout -b <branch-name>
删除分支
git branch -d <branch-name>
如果在指定的分支有一些unmerged的提交，删除分支会失败，这里可以使用-D参数强制删除分支。
git branch -D <branch-name>
检出分支或提交
检出某一分支或某一提交是同一个命令
git checkout <branch-name> | <commit>
分支合并(merge)
当我们新建一个分支进行开发，并提交了几次更新后，感觉是时候将这个分支的内容合回主线了，这是就可以取出主线分支，然后把分支的更新merge回来：
git checkout master
git merge testing
如果master分支是testing分支的直接上游，即从master延着testing分支的提交历史往前走可以直接走到testing分支的最新提交，那么系统什么也不需要做，只需要改变master分支的指针即可，这被称之为"Fast Forward"。
但是，一般情况是这样的，你取出了最新的master分支，比如说master分支最新的提交是C2（假设共3次提交C0<-C1<-C2)，在此基础上你新建了分支，当你在分支上提交了C3、C5后想将br1时merge回master时，你发现已经有其他人提交了C4，这时候就不能直接修改master的指针了，不然会丢失别人的提交，这个时候就需要将你新建分支时master所在的提交（C2）后的修改（C4），与你新建分支后在分支上的修改（C3、C5)做合并，将合并后的结果作为一个新的提交提交到master，GIT可以自动推导出应该基于哪个提交进行合并（C2），如果没有冲突，系统会自动提交新的提交，如果有冲突，系统会提示你解决冲突，当冲突解决后，你就可以将修改加入暂存区并提交。提交历史类似下面这样（图来自Pro-Git)：
merge后的提交是按时间排序的，比如下图，我们在rename提交处新建分支test，在test上提交Commit from branch test，然后回到master提交commit in master after committing in branch，再将test分支merge进master，这时看提交提交历史，Commit from branch test是在commit in master...之前的，尽管在master上我们是在rename的基础上提交的commit in master...而GIT会在最后添加一个新的提交（Merge branch ‘test‘）表示我们在此处将一个分支merge进来了。这种情况会有一个问题，比如说在rename提交处某人A从你这里Copy了一个GIT仓库，然后你release了一个patch（通过git format-patch）给A，这时候test分支还没有merge进来，所以patch中只包含提交：commit in master...然后你把test分支merge了进来又给了A一个patch，这个patch会包含提交：Commit from branch test，而这个patch是以rename为base的，如果commit in master...和Commit from branch test修改了相同的文件，则第二次的patch可能会打不上去，因为以rename为base的patch可能在新的Code上找不到在哪个位置应用修改。
分支衍合(rebase)
有两种方法将一个分支的改动合并进另一个分支，一个就是前面所说的分支合并，另一个就是分支衍合，这两种方式有什么区别呢？
分支合并（merge）是将两个分支的改动合并到一起，并生成一个新的提交，提交历史是按时间排序的，即我们实际提交的顺序，通过git log --graph或一些图形化工具，可能很明显地看到分支的合并历史，如果分支比较多就很混乱，而且如果以功能点新建分支，等功能点完成后合回主线，由于merge后提交是按提交时间排序的，提交历史就比较乱，各个功能点的提交混杂在一起，还可能遇到上面提到的patch问题。
而分支衍合（rebase）是找到两个分支的共同祖先提交，将要被rebase进来的分支的提交依次在要被rebase到的分支上重演一遍，即回到两个分支的共同祖先，将branch（假如叫experiment）的每次提交的差异保存到临时文件里，然后切换到要衍合入的分支（假如是master），依次应用补丁文件。experiment上有几次提交，在master就生成几次新的提交，而且是连在一起的，这样合进主线后每个功能点的提交就都在一起，而且提交历史是线性的
对比merge与rebase的提交历史会是下图这样的（图来自Pro-GIt）：
（merge）
（rebase）
rebase后C3提交就不存在了，取而代之的是C3‘，而master也成为了experiment的直接上游，只需一次Fast Forward（git merge）后master就指向了最新的提交，就可以删除experiment分支了。
衍合--onto
git rebase --onto master server client
这条命令的意思是：检出server分支与client分支共同祖先之后client上的变化，然后在master上重演一遍。
父提交
HEAD表示当前所在的提交，如果要查看当前提交父提交呢？git log查看提交历史，显然太麻烦了，而且输入一长串的Commit-ID也不是一个令人愉悦的事。这时可借助两个特殊的符号：~与^。
^ 表示指定提交的父提交，这个提交可能有多个父提交，^之后跟上数字表示第几个父提交，不跟数字等同于^1。
~n相当于n个^，比如~3=^^^，表示第一个父提交的第一个父提交的第一个父提交。
远程分支
远程分支以(远程仓库名)/(分支名)命令，远程分支在本地无法移动修改，当我们clone一个远程仓库时会自动在本地生成一个名叫original的远程仓库，下载远程仓库的所有数据，并新建一个指向它的分支original/master，但这个分支我们是无法修改的，所以需要在本地重新一个分支，比如叫master，并跟踪远程分支。
Clone了远程仓库后，我们还会在本地新建其他分支，并且可能也想跟踪远程分支，这时可以用以下命令：
git checkout -b [branch_name] --track|-t <remote>/<remote-banch>
和新建分支的方法一样，只是加了一个参数--track或其缩写形式-t，可以指定本地分支的名字，如果不指定就会被命名为remote-branch。
要拉取某个远程仓库的数据，可以用git fetch:
git fetch <remote>
当拉取到了远程仓库的数据后只是把数据保存到了一个远程分支中，如original/master，而这个分支的数据是无法修改的，此时我们可以把这个远程分支的数据合并到我们当前分支
git merge <remote>/<remote-branch>
如果当前分支已经跟踪了远程分支，那么上述两个部分就可以合并为一个
git pull
当在本地修改提交后，我们可能需要把这些本地的提交推送到远程仓库，这里就可以用git push命令，由于本地可以由多个远程仓库，所以需要指定远程仓库的名字，并同时指定需要推的本地分支及需要推送到远程仓库的哪一个分支
git push <remote> <local-branch>:<remote-branch>
如果本地分支与远程分支同名，命令可以更简单
git push <remote> <branch-name> 等价于 git push <remote> refs/heads/<branch-name>:refs/for/<branch-name>
如果本地分支的名字为空，可以删除远程分支。
前面说过可以有不止一个远程分支f，添加远程分支的方法为
git remote add <short-name> <url>
六、标签-tag
作为一个版本控制工具，针对某一时间点的某一版本打tag的功能是必不可少的，要查看tag也非常简单，查看tag使用如下命令
git tag
参数"-l"可以对tag进行过滤
git tag -l "v1.1.*"
Git 使用的标签有两种类型：轻量级的（lightweight）和含附注的（annotated）。轻量级标签就像是个不会变化的分支，实际上它就是个指向特定提交对象的引用。而含附注标签，实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字，电子邮件地址和日期，以及标签说明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。
轻量级标签只需在git tag后加上tag的名字，如果tag名字
git tag <tag_name>
含附注的标签需要加上参数-a（annotated），同时加上-m跟上标签的说明
git tag -a <tag_name> -m "<tag_description>"
如果你有自己的私钥，还可以用 GPG 来签署标签，只需要把之前的 -a 改为 -s（signed）
查看标签的内容用
git show <tag_name>
验证已签署的标签用-v（verify）
git tag -v <tag_name>
有时在某一个版本忘记打tag了，可以在后期再补上，只需在打tag时加上commit-id
要将tag推送到远程服务器上，可以用
git push <remote> <tag_name>
或者可以用下面的命令推送所有的tag
git push <remote> --tags
七、Git配置
使用"git config"可以配置Git的环境变量，这些变量可以存放在以下三个不同的地方：
/etc/gitconfig 文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system选项，读写的就是这个文件。
~/.gitconfig 文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global选项，读写的就是这个文件。
当前项目的 git 目录中的配置文件（也就是工作目录中的 .git/config 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖/etc/gitconfig 中的同名变量。
在 Windows 系统上，Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录，一般都是 C:\Documents and Settings\$USER。此外，Git 还会尝试找寻 /etc/gitconfig 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。
最基础的配置是配置git的用户，用来标识作者的身份
git config --global user.name <name>
git config --global user.email <email>
文本编辑器也可以配置，比如在git commit的时候就会调用我们设置的文本编辑器
git config --global core.editor vim
另一个常用的是diff工具，比如我们想用可视化的对比工具
git config --global merge.tool meld
要查看所有的配置，可以用
git config --list
或者可以在git config后加上配置项的名字查看具体项的配置
git config user.name
作为一个懒人，虽然checkout、status等命令只是一个单词，但是还是嫌太长了，我们还可以给命令设置别名如
git config --global alias.co checkout
这样git co就等于git checkout
前面说地，git配置项都保存在那3个文件里，可以直接打开相应的配置文件查看配置，也可以直接修改这些配置文件来配置git，想删除某一个配置，直接删除相应的行就行了
八、其他
关于GIT各命令的说明可以查看相关帮助文档，通过以下方法：
git help <command>或git <command> --help
标签：git
原文地址：http://tenderrain.blog.51cto.com/9202912/1881970
