Git服务器（CTP2交易用）地址：http://172.24.118.134:7990，用户名和密码为姓名全拼 ，注意修改密码。

Git服务器（练习用）地址：http://172.24.118.130:7990，用户名和密码为姓名全拼，注意修改密码。

Git 图形界面客户端选用TortoiseGit。

Git分支的本质

Git的分支实质上是一个包含所指对象校验和（一般就是长度为50的字符串）的文件，可以看作指向提交对象的可变指针。

HEAD指向当前所在的分支（将HEAD想像为当前分支的别名），并随着提交操作自动向前移动。当切换/检出时，HEAD也随之移动。

切换分支后，工作里的目录会改变，如果是切换到一个较旧的分支，工作目录会恢复到该分支最后一次提交时的样子。

Git分支的新建、合并与删除

考虑一种复杂场景：在iss53分支上进行了开发，进行了一半，此时又需要在主分支上创建一个hotfix分支进行修改。

7步解决方案：

1）在iss53分支上保存进度(stashing)或者修补提交(commit appending)，以下步骤是建立在已经把iss53分支上的修改全部提交的基础上；

2）创建并切换到hotfix分支，修改，提交（提交时请注意添加注释，养成良好习惯）；

3）在master分支上将hotfix分支合并回master分支

4） 删除hotfix分支，切换到iss53分支（注意之前在hotfix上所作的工作并没有包含到iss53分支中），继续开发并提交

5）如果需要拉取hotfix所作的修改，可以将master分支合并入iss53分支，或者等iss53分支完成使命后合并回master分支。（该步骤为可选步骤）

6）检出到你想合并入的分支即master分支，执行合并操作，因为分叉了，所以此时的合并其实是一个三方合并（C4、C5和C2），并且自动创建一次合并提交C6

7） 删除iss53分支

遇到冲突时的分支合并

考虑一种场景：当在两个不同的分支中对同一个文件的同一个部分进行了不同的修改，Git就无法顺利合并。比如当对iss53的修改和hotfix的修改都涉及到同一个文件的同一处，在合并时就会产生冲突。此时任何因包含合并冲突而有待解决的文件都会以未合并状态标识出来。

手动解决冲突的办法是：仅保留一个分支的修改，添加，处于暂存区就表明冲突已被解决。

分支开发工作流与分支策略（branching scheme）

1）长期分支/稳定分支

简单而言，思想就是：经过测试考验的提交会被遴选到更加稳定的流水线（work silos）上去，可以用这种方法维护不同层次的稳定性。

2）特性分支/短期分支/临时分支

简单而言，思想就是：工作被分散到不同的流水线。

上一节中涉及的iss53分支和hotfix分支都属于特性分支，之所以是短期分支，是因为将他们合并（等待成熟之后再合并也不迟）入长期分支后就删除了。

远程分支

前面所述的分支存于本地，分支操作也是发生于本地，并没有与服务器发生交互。

origin是当你运行Git 克隆命令时默认的远程仓库的名字，同理，默认的远程分支的名字是origin/master，如下图所示：

这时很容易产生这样的场景，别人推送至服务器的master分支了，你还在本地的分支上折腾。

此时需要用到拉取PULL功能：查找origin是哪一个服务器，从中抓取本地没有的数据，更新本地数据库，移动origin/master指针指向新的、更新后的位置。

推送PUSH

如果希望和别人一起在名为serverfix的分支上工作，那就推送本地的serverfix分支来更新远程仓库上的serverfix分支，这样下一次项目的其它协作者从服务器上抓取（有待确定）数据时，会在他们的本地生成一个远程分支origin/serverfix，指向服务器的serverfix分支的引用，然后在其本地创建一个serverfix分支。

删除远程分支：假设已经通过远程分支（比如这个serverfix）完成所有的工作了，意思就是你和你的协作者已经完成了一个特性并且将其合并到了远程仓库的master分支，那么就可以删除了（在本地就可以删除远程分支了）

抓取FETCH

该操作会查找当前分支所跟踪的服务器与分支，然后抓取克隆后或者上一次抓取后新推送的所有工作到你的本地仓库，但不会自动合并或修改你当前的工作，需要手动合并。

拉取PULL

一般是抓取+合并一起执行，该操作会查找当前分支所跟踪的服务器与分支，然后从服务器抓取数据，最后合并远程分支到当前分支。