Git全过程（三）


五、Git分支

在代码版本控制工具中，都会有branch的概念。刚开始建立版本仓库的时候，我们只有一个主分支（master branch），我们不可能把日常的新功能开发、代码优化以及bug修复等概念工作全都放在主分支上，这样会使主分支很难维护。这就是为什么会有branch。

分支的创建

在Git中，branch的创建很简单，我们可以通过下面的命令创建一个”release-1.0″的branch。

然后通过”checkout”命令来切换branch。

在Git中，我们可以通过”git checkout -b”命令来达到同时创建并切换branch的效果。

注意：大家一定还记得第二篇文章中我们通过”checkout”命令来还原WorkSpace中的更新，在还原的命令中我们使用的是”checkout –”，如果没有”–”就代表切换branch。

根据前面两篇文章的知识，我们进入”.git/refs/heads”目录，发现有”HEAD”和”release-1.0″两个文件，并且两个文件包含的哈希值相同，根据”git log”可以知道这个哈希值代表master上最新的提交。所以，创建分支后我们会得到下面的关系图，从值张图中可以看到，branch的切换对应HEAD引用值的改变。



有了新的branch之后，我们就可以分别在不同的branch上工作了。假设我们现在更新”app.py”，并且在release-1.0 branch上面提交，重新查看对象关系图。



根据上面的对象图，可以分析出以下信息：

“ref/heads/release-1.0″文件内的哈希值将更新为release-1.0 branch上最新的更新

release-1.0 branch上面的更新不会体现在master branch

经过查看，”ref/heads/release-1.0″文件的内容确实是release-1.0 branch上最新的更新。并且，当我们切换到master branch的时候，所有master上的东西都没有变化。

分支的删除

分支的删除比较简单，可以使用”git branch -d”命令。

分支的合并

branch的创建是为了方便开发、修复bug以及保持master的稳定。但是最终branch上的内容还是要合并到master的，接下来就看看分支的合并。

在Git中，可以通过”Git merge”来合并分支，继续前面的例子，我们可以把”app.py”的更新merge到master branch上。

这时候，master的HEAD就被更新了，跟release-1.0内容一致了，这些就是merge命令做的事情。



合并冲突

在branch的合并中，很多时候我们会遇到冲突，那么我们就需要手动解决冲突，然后再提交了。

master和release-1.0上同时修改了”app.py”，合并时引起了冲突。在Git中，会用”<<<<<<<”，”=======”，”>>>>>>>”标记出冲突区域，我们需要根据这些符号找到所有的冲突并解决。

同时，这里给出最新的对象关系图:



branch相关操作

在branch的使用过程中，我们还会经常使用到stash和diff操作，下面分别进行介绍。

stash

在Git中，stash是个很有用的命令，可以保存我们做到一半的工作，可以理解成一个未完成工作的保存区。

假如我们在release-1.0 branch做了一些更新，但是想做的事情还没有全部完成，不能提交，这是我们又要切换到master branch，这是Git会禁止branch切换。

使用场景：

使用git的时候，我们往往使用branch解决任务切换问题，例如，我们往往会建一个自己的分支去修改和调试代码, 如果别人或者自己发现原有的分支上有个不得不修改的bug，我们往往会把完成一半的代码 commit提交到本地仓库，然后切换分支去修改bug，改好之后再切换回来。这样的话往往log上会有大量不必要的记录。其实如果我们不想提交完成一半或者不完善的代码，但是却不得不去修改一个紧急Bug，那么使用'git stash'就可以将你当前未提交到本地（和服务器）的代码推入到Git的栈中，这时候你的工作区间和上一次提交的内容是完全一样的，所以你可以放心的修 Bug，等到修完Bug，提交到服务器上后，再使用'git stash apply'将以前一半的工作应用回来。也许有的人会说，那我可不可以多次将未提交的代码压入到栈中？答案是可以的。当你多次使用'git stash'命令后，你的栈里将充满了未提交的代码，这时候你会对将哪个版本应用回来有些困惑，'git stash list'命令可以将当前的Git栈信息打印出来，你只需要将找到对应的版本号，例如使用'git stash apply stash@{1}'就可以将你指定版本号为stash@{1}的工作取出来，当你将所有的栈都应用回来的时候，可以使用'git stash clear'来将栈清空。
在这里顺便提下git format-patch -n , n是具体某个数字， 例如 'git format-patch -1' 这时便会根据log生成一个对应的补丁，如果 'git format-patch -2' 那么便会生成2个补丁，当然前提是你的log上有至少有两个记录。

stash命令详解：

git stash 对当前的暂存区和工作区状态进行保存。

git stash list 列出所有保存的进度列表。

git stash pop [--index] [<stash>] 恢复工作进度

git stash [save message] [-k|--no-keep-index] [--patch]

git stash apply [--index] [<stash>] 不删除已恢复的进度，其他同git stash pop

git stash drop [<stash>] 删除某一个进度，默认删除最新进度

git stash clear 删除所有进度

git stash branch <branchname> <stash> 基于进度创建分支

branch之间的diff

在前面的文章中我们通过diff比较过同一个分支上的内容在WrokSpace、stage和repo中的差别。

同样diff可以支持分支之间的比较。

git diff branchName：把当前branch跟branchName进行比较，也可以使用”git diff branchNameA branchNameB”

git diff branchName — fileName：比较两个branch的fileName文件差异

六、Git远程仓库

在Git系统中，用户可以通过push/pull命令来推送/获取别的开发人员的更新，当时对于一个工作组来说，这种方式会效率比较低。所以，在一个Git系统中，都会有一个中心服务器，大家都通过中心服务器来推送/获取更新。

为了方便本篇例子的进行，我就使用多个目录来模拟多个用户以及中心服务器，这样就不用搭建Git服务器了。

中心服务器：C:\VM\CentralRepo

用户wilber：C:\VM\wilberWorkSpace

用户will：C:\VM\willWorkSpace

Git远程仓库命令

建立中心服务器

通过前面的文章我们知道可以通过”git init”来建立一个Git仓库，这里，我们使用”git init –bare”来建立中心仓库，注意”–bare”参数，后面进行介绍。

到这里，一个空的中心服务器就建好了。

Clone一个仓库

在Git中，我们有两种方式建立Git仓库：一个是通过”git init”建立一个新的仓库，另一个是通过”git clone”命令clone一个已有的Git仓库。

既然中心服务器，用户will就可以通过clone命令来复制一个Git仓库。

在clone命令中需要给出目标仓库的地址，Git支持http、ssh以及git原生协议来进行clone。

–bare

现在我们看看建立中心服务器时候用到的”–bare”选项。

“git init –bare”方法创建的是一个裸仓库，之所以叫裸仓库是因为这个仓库只保存Git历史提交的版本信息，而不允许用户在上面进行各种git操作。

之所以有裸仓库，是因为用”git init”初始化的版本库，用户也可以在该目录下执行所有git方面的操作。但别的用户在将更新push上来的时候容易出现冲突。在这种情况下，最好就是使用”–bare”选项建立一个裸仓库。

上游仓库(upstream repository)

在Git系统中，通常用”origin” 来表示上有仓库。我们可以通过 “git branch -r”命令查看上游仓库里所有的分支，再用 origin/name-of-upstream-branch 的名字来抓取(fetch)远程追踪分支里的内容。

对于wilber的仓库，master分支的上游分支是中心服务器的master分支。

牛叉的patch

在Git中patch绝对是一个很有用的东西。假设在一个没有网络的环境中，wilber和will还要继续工作，这时wilber有一个更新，will需要基于这个更新进行下一步的工作。如果是集中式的代码版本工具，这种情况就没有办法工作了，但是在Git中，我们就可以通过patch的方式，把wilber的更新拷贝给will。

在Git中有两种patch的方式：一是通过”git diff”生成一个标准的patch，另一个是通过”git format-patch”生成一个Git专用的patch。

基于”git diff”的patch与基于”git format-patch”的patch

两种patch方式的比较

下面简单看看两种patch方式的比较。

patch兼容性：”git diff”生成的patch兼容性强。也就是说，如果别人的代码版本库不是Git，那么必须使用git diff生成的patch才能被别的版本控制系统接受。

patch合并提示：对于”git diff”生成的patch，你可以用git apply –check 查看patch是否能够干净顺利地应用到当前分支中；如果”git format-patch” 生成的patch不能打到当前分支，git am会给出提示，帮你解决冲突，两者都有较好的提示功能。

patch信息管理：通过”git format-patch”生成的patch中有很多信息，比如开发者的名字，因此在应用patch时，这个名字会被记录进版本库，这样做是比较合理的。

参考文档：http://git-scm.com/book/zh/ch2-5.html