[开发工具]Git学习--高级

1、分支

在开发软件时，可能有多人同时为同一个软件开发功能或修复BUG，可能存在多个Release版本，并且需要对各个版本进行维护。

所幸，Git的分支功能可以支持同时进行多个功能的开发和版本管理。

什么是分支？

分支是为了将修改记录的整体流程分叉保存。分叉后的分支不受其他分支的影响，所以在同一个数据库里可以同时进行多个修改。

分叉的分支可以合并。

为了不受其他开发人员的影响，您可以在主分支上建立自己专用的分支。完成工作后，将自己分支上的修改合并到主分支。因为每一次提交的历史记录都会被保存，所以当发生问题时，定位和修改造成问题的提交就容易多了。

Master

在数据库进行最初的提交后, Git会创建一个名为master的分支。因此之后的提交，在切换分支之前都会添加到master分支里。

1.1、merge

Merge分支是为了可以随时发布release而创建的分支，它还能作为Topic分支的源分支使用。保持分支稳定的状态是很重要的。如果要进行更改，通常先创建Topic分支，而针对该分支，可以使用Jenkins之类的CI工具进行自动化编译以及测试。

通常，大家会将master分支当作Merge分支使用。

1.2、topic

Topic分支是为了开发新功能或修复Bug等任务而建立的分支。若要同时进行多个的任务，请创建多个的Topic分支。

Topic分支是从稳定的Merge分支创建的。完成作业后，要把Topic分支合并回Merge分支。

1.3、分支的切换

若要切换作业的分支，就要进行checkout操作。进行checkout时，git会从工作树还原向目标分支提交的修改内容。checkout之后的提交记录将被追加到目标分支。

HEAD

HEAD指向的是现在使用中的分支的最后一次更新。通常默认指向master分支的最后一次更新。通过移动HEAD，就可以变更使用的分支。

Stash

还未提交的修改内容以及新添加的文件，留在索引区域或工作树的情况下切换到其他的分支时，修改内容会从原来的分支移动到目标分支。

但是如果在checkout的目标分支中相同的文件也有修改，checkout会失败的。这时要么先提交修改内容，要么用stash暂时保存修改内容后再checkout。

stash是临时保存文件修改内容的区域。stash可以暂时保存工作树和索引里还没提交的修改内容，您可以事后再取出暂存的修改，应用到原先的分支或其他的分支上。

1.4、分支的合并

• merge

直接移动分支为快速，涉及到修改、解决冲突则为non fast-forward

使用merge可以合并多个历史记录的流程。

如下图所示，bugfix分支是从master分支分叉出来的。

?

合并 bugfix分支到master分支时，如果master分支的状态没有被更改过，那么这个合并是非常简单的。 bugfix分支的历史记录包含master分支所有的历史记录，所以只要把bugfix移动到master分支就可以导入bugfix分支的内容了。这样的合并被称为fast-forward（快进）合并。

但是，master分支的历史记录有可能在bugfix分支分叉出去后有新的更新。这种情况下，要把master分支的修改内容和bugfix分支的修改内容汇合起来。

?

因此，合并两个修改会生成一个提交。这时，master分支的HEAD会移动到该提交上。

执行合并时，如果设定了non fast-forward选项，即使在能够fast-forward合并的情况下也会生成新的提交并合并。

执行non fast-forward后，分支会维持原状。那么要查明在这个分支里的操作就很容易了。

• rebase

图片参照文章末尾给的网址

跟merge的例子一样，如下图所示，bugfix分支是从master分支分叉出来的。

如果使用rebase方法进行分支合并，会出现下图所显示的历史记录。现在我们来简单地讲解一下合并的流程吧。

首先，rebase bugfix分支到master分支, bugfix分支的历史记录会添加在master分支的后面。如图所示，历史记录成一条线，相当整洁。

这时移动提交X和Y有可能会发生冲突，所以需要修改各自的提交时发生冲突的部分。

rebase之后，master的HEAD位置不变。因此，要合并master分支和bugfix分支，即是将master的HEAD移动到bugfix的HEAD这里。

Merge和rebase都是合并历史记录，但是各自的特征不同。

• merge 保持修改内容的历史记录，但是历史记录会很复杂。

• rebase 历史记录简单，是在原有提交的基础上将差异内容反映进去。 因此，可能导致原本的提交内容无法正常运行。

您可以根据开发团队的需要分别使用merge和rebase。 例如，想简化历史记录，

• 在topic分支中更新merge分支的最新代码，请使用rebase。

• 向merge分支导入topic分支的话，先使用rebase，再使用merge。

2、操作分支

//显示分支清单
$ git branch
//创建
$ git branch <branchname>
//修改
$ git branch -m <oldbranch> <newbranch>
//删除
$ git branch -d <branchname>
//切换
$ git checkout <branch>
//合并
$ git merge <branch>

建立本地空数据库，并git init初始化

创建文本文件，编辑好内容。

然后提交

?

2.1、建立分支

//创建名为issue1的分支。
git branch issue1
//不指定参数直接执行branch命令的话，可以显示分支列表。 前面有*的就是现在的分支。
$ git branch
  issue1
* master

2.2、切换

若要在新建的issue1分支进行提交，需要切换到issue1分支。

要执行checkout命令以退出分支。

$ git checkout issue1
Switched to branch 'issue1'

在checkout命令指定 -b选项执行，可以创建分支并进行切换。

$ git checkout -b <branch>

在切换到issue1分支的状态下提交，历史记录会被记录到issue1分支。在myfile.txt添加add命令的说明后再提交。

?

2.3、合并分支

向master分支合并issue1分支的修改。

执行merge命令以合并分支。$ git merge <commit>

该命令将指定分支导入到HEAD指定的分支。先切换master分支，然后把issue1分支导入到master分支。

打开myfile.txt档案以确认内容。

已经在issue1分支进行了编辑上面的档案，所以master分支的myfile.txt的内容没有更改。

master分支指向的提交移动到和issue1同样的位置。这个是fast-forward（快进）合并。

打开myfile.txt档案，确认内容。

2.4、删除分支

?

2.5、并行操作

接下来，创建2个分支来尝试并行操作吧

首先创建issue2分支和issue3分支，并切换到issue2分支。

?在issue2分支的myfile.txt添加commit命令的说明后提交。

?

?

接着，切换到issue3分支。

打开myfile.txt档案。由于在issue2分支添加了commit命令的说明，所以issue3分支的myfile.txt里只有add命令的说明。

添加pull命令的说明后提交。

?

这样，添加commit的说明的操作，和添加pull的说明的操作就并行进行了。

2.6、解决合并冲突

把issue2分支和issue3分支的修改合并到master。

切换master分支后，与issue2分支合并。

执行fast-forward（快进）合并。

接着合并issue3分支。

?

自动合并失败。由于在同一行进行了修改，所以产生了冲突。这时myfile.txt的内容如下：

?

将格式符合去掉，采用两个修改：

重新提交

历史记录如下图所示。因为在这次合并中修改了冲突部分，所以会重新创建合并修改的提交记录。这样，master的HEAD就移动到这里了。这种合并不是fast-forward合并，而是non fast-forward合并。

?

2.7、rebase合并

合并issue3分支的时候，使用rebase可以使提交的历史记录显得更简洁。

现在暂时取消刚才的合并。

$ git reset --hard HEAD~

切换到issue3分支后，对master执行rebase。

和merge时的操作相同，修改在myfile.txt发生冲突的部分。

rebase的时候，修改冲突后的提交不是使用commit命令，而是执行rebase命令指定 --continue选项。若要取消rebase，指定 --abort选项。

这样，在master分支的issue3分支就可以fast-forward合并了。切换到master分支后执行合并。

?myfile.txt的最终内容和merge是一样的，但是历史记录如下。

?

3、远端数据库

• 3.1、pull

首先确认更新的本地数据库分支没有任何的更改。

这时只执行fast-forward合并。master是本地数据库的master分支，origin/master是远程数据库的origin的master分支。

如果本地数据库的master分支有新的历史记录，就需要合并双方的修改。

执行pull就可以进行合并。这时，如果没有冲突的修改，就会自动创建合并提交。如果发生冲突的话，要先解决冲突，再手动提交。

• 3.2、fetch

执行pull，远程数据库的内容就会自动合并。但是，有时只是想确认本地数据库的内容而不想合并。这种情况下，请使用fetch。

执行fetch就可以取得远程数据库的最新历史记录。

在fetch后这个状态下，若要把远程数据库的内容合并到本地数据库，可以合并，或者重新执行pull。

• 3.3、push

从本地数据库push到远程数据库时，要fast-forward合并push的分支。如果发生冲突，push会被拒绝的。

若要共享在本地数据库创建的分支，需要明确的push。因此，没有执行push就不会给远程数据库带来影响，因而可以自由的创建自己的分支。

基本上，远程数据库共享的提交是不能修改的。如果修改的话，跟远程数据库同步的其他数据库的历史记录会变得很奇怪的。

4、标签

//查看
$ git tag
//建立
$ git tag <tagname>
//建立含批注的标签
$ git tag -a <tagname>
//删除
$ git tag -d <tagname>

标签是为了更方便地参考提交而给它标上易懂的名称。

Git可以使用2种标签：轻标签和注解标签。打上的标签是固定的，不能像分支那样可以移动位置。如果要移动标签，必须先删除标签再重新打上标签。

• 轻标签

  • 添加名称

• 注解标签

  • 添加名称

  • 添加注解

  • 添加签名

一般情况下，发布标签是采用注解标签来添加注解或签名的。轻标签是为了在本地暂时使用或一次性使用。

您可以指定标签名称以退出，或reset在「修改提交」的讲解，还可以简单的恢复过去特定的状态。

4.1、操作标签

首先建立一个新目录，并在里面建立一个空数据库。这里我们创建一个名为mygitTag的目录。

git init 之后，创建一个myfile.txt文档，输入git 标签学习

然后添加索引并提交。

1、添加轻标签

//使用tag命令来添加标签，在<tagname>执行标签的名称。
$ git tag <tagname>
//在HEAD指向的提交里添加名为apple的标签，请执行以下的命令。
$ git tag apple
//如果没有使用参数而执行tag，可以显示标签列表。
$ git tag
apple
//如果在log命令添加 --decorete选项执行，可以显示包含标签资料的历史记录。

?2、添加注解标签

//若要添加注解标签，可以在tag命令指定 -a选项执行。执行后会启动编辑区，请输入注解，也可以指定-m
//选项来添加注解。
$ git tag -a <tagname>
//在HEAD指向的提交里添加名为banana的标签，请执行以下的命令。
$ git tag -am "可导必连续" banana
//如果在tag命令指定-n选项执行，可以显示标签的列表和注解。
$ git tag -n

//若要删除标签，在tag命令指定 -d选项执行。
$ git tag -d <tagname>

5、改写提交

5.1、修改最近的提交

指定amend选项执行提交的话，可以修改同一个分支最近的提交内容和注解。

$ git add sample.txt
$ git commit --amend

主要使用的场合：

• 添加最近提交时漏掉的档案

• 修改最近提交的注解

5.2、取消过去的提交

在revert可以取消指定的提交内容。使用后面要提到的rebase -i或reset也可以删除提交。但是，不能随便删除已经发布的提交，这时需要通过revert创建要否定的提交。

$ git revert HEAD

revert是取消了提交内容，但也创建了取消提交历史记录，而reset则直接删除了提交。

主要使用的场合：

• 安全地取消过去发布的提交

5.3、遗弃提交

在reset可以遗弃不再使用的提交。执行遗弃时，需要根据影响的范围而指定不同的模式，可以指定是否复原索引或工作树的内容。

$ git reset --hard HEAD~~
//在reset之前的提交可以参照ORIG_HEAD。Reset错误的时候，在ORIG_HEAD上reset 就可以还原
//到reset前的状态。
$ git reset --hard ORIG_HEAD

除了默认的mixed模式，还有soft和hard模式。欲了解受各模式影响的部分，请参照下面的表格。

主要使用的场合：

• 复原修改过的索引的状态(mixed)

• 彻底取消最近的提交(hard)

• 只取消提交(soft)

5.4、提取提交

在cherry-pick，您可以从其他分支复制指定的提交，然后导入到现在的分支。

主要使用的场合：

• 把弄错分支的提交移动到正确的地方

• 把其他分支的提交添加到现在的分支

5.5、改写提交的历史记录

在rebase指定i选项，您可以改写、替换、删除或合并提交。

汇合提交：

//若要汇合过去的提交，请用rebase -i。
$ git rebase -i HEAD~~
//打开文本编辑器，将看到从HEAD到HEAD~~的提交

将第二行的“pick”改成“squash”，然后保存并退出。由于合并后要提交，所以接着会显示提交信息的编辑器，请编辑信息后保存并退出。

这样，两个提交就合并成一个提交了。请用log命令确认历史记录。

修改提交：

用rebase -i ，首先选择要修改的提交。

$ git rebase -i HEAD~~
//打开文本编辑器，将看到从HEAD到HEAD~~的提交

主要使用的场合：

• 在push之前，重新输入正确的提交注解

• 清楚地汇合内容含义相同的提交。

• 添加最近提交时漏掉的档案

5.6、汇合分支上的提交，然后一同合并到分支

我们介绍一下merge的特殊选项：squash

用这个选项指定分支的合并，就可以把所有汇合的提交添加到分支上。

$ git checkout master
$ git merge --squash issue1

主要使用的场合：

• 汇合主题分支的提交，然后合并提交到目标分支。

以上步骤均参考网站：猴子都能懂的GIT入门 | 贝格乐（Backlog）