Git分支实战入门详细图解

Posted 2021-11-07 velscode

现在我们模拟一个简单的分支和合并案例，其中工作流可供真实项目借鉴。

（1）在master开展工作
（2）为新的需求创建分支
（3）在新的分支上展开工作
这时，你接到一个电话，说项目有一个严重的问题需要紧急修复。你随后会这样做：
（4）切换到你的生产环境分支
（5）创建新的分支来进行此次问题的热修补工作
（6）通过测试后，合并热修补分支并推送到生产环境中
（7）切换回之前的需求分支上继续工作

基本的分支操作

首先，假设你在所工作的项目上已经完成了一些提交

$ git log --oneline --decorate --graph --all
* 5d55df0 (HEAD -> master) 先前的工作2
* 36228f1 先前的工作1

这时，你决定在工程中加入功能模块B，所以你创建了一个分支mod-b

$ git checkout -b mod-b
Switched to a new branch ‘mod-b‘

D:\\Git\\t2 (mod-b -> origin)

接下来你继续工作，进行了新的提交。这么做会让mod-b分支指针向前移动。

$ git log --oneline --decorate --graph --all
* b52c200 (HEAD -> mod-b) 创建了模块B
* 5d55df0 (master) 先前的工作2
* 36228f1 先前的工作1

现在，你接到一个电话，说项目有个问题需要立即被修复。如果没有Git的帮助，你需要先取消所有针对模块B所做的修改，然后部署补丁。如今你要做的就是切换回master分支即可。

$ git checkout master
Switched to branch ‘master‘

D:\\Git\\t2 (master -> origin)

此时项目的状态就和你开始处理模块B之前一模一样了，你可以集中精力制作补丁了。我们接下来创建一个补丁分支fix，并展开一些工作提交。

$ git checkout -b fix
Switched to a new branch ‘fix‘

$ git commit -a -m "修补了线上的问题"
[fix 130f52e] 修补了线上的问题
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 fix.txt

现在我们再查看一下分支结构

$ git log --oneline --decorate --graph --all
* 130f52e (HEAD -> fix) 修补了线上的问题
| * b52c200 (mod-b) 创建了模块B
|/
* 5d55df0 (master) 先前的工作2
* 36228f1 先前的工作1

现在你确定这个补丁准确无误，将其合并到master分支

$ git checkout master
Switched to branch ‘master‘

$ git merge fix
Updating 5d55df0..130f52e
Fast-forward
 fix.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 fix.txt

注意到，合并过程出现了fast-forward提示。由于当前所在master分支所指向的提交是要并入fix分支的直接上游，因而Git会将master分支指针向前移动。换句话说，当你试图合并两个不同的提交，而顺着其中一个的提交的历史可以直接到达另一个提交时，Git就会简化合并操作，直接把分支指针向前移动，因为这种单线历史不存在有分歧的工作，这就叫做fast-forward。

现在，我们的分支是这样的

$ git log --oneline --decorate --graph --all
* 130f52e (HEAD -> master, fix) 修补了线上的问题
| * b52c200 (mod-b) 创建了模块B
|/
* 5d55df0 先前的工作2
* 36228f1 先前的工作1

问题修复完毕，你准备回到之前被打断的工作上去，继续优化你的模块B。再此之前，先别急，首先把已经不需要的分支fix删除，该分支和master分支指向的位置相同。使用git branch的-d选项来删除这个分支

$ git branch -d fix
Deleted branch fix (was 130f52e).

现在，回到mod-b分支，优化模块B

$ git checkout mod-b
Switched to branch ‘mod-b‘

# 对B模块做了一些优化

$ git commit -a -m "优化了模块B"
[mod-b 65f2937] 优化了模块B
 1 file changed, 1 insertion(+), 1 deletion(-)

看现在的分支

$ git log --oneline --decorate --graph --all
* 65f2937 (HEAD -> mod-b) 优化了模块B
* b52c200 创建了模块B
| * 130f52e (master) 修补了线上的问题
|/
* 5d55df0 先前的工作2
* 36228f1 先前的工作1

值得注意的是，mod-b分支不包含你在fix上做过的工作。如果需要把上述修补工作并入mod-b，就需要执行git merge master使得master分支合并到mod-b分支中，或者把mod-b分支合并入master分支。

基本的合并操作

现在模块B的工作已经完成，可以合并会master分支了。这次合并操作实现起来与之前合并fix分支差不多

$ git checkout master
Switched to branch ‘master‘

$ git merge mod-b
Merge made by the ‘recursive‘ strategy.
 b.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 b.txt

这次合并看起来有点不一样。这次合并中，开发历史从某个早先的时间点开始有了分叉。由于当前master指向的提交并不是mod-b的直接祖先，因而Git必须要做一些额外的工作。本例中，Git执行的是简单的三方合并。三方合并操作会使用两个待合并分支上最新提交的快照，以及这两个分支的共同祖先的提交快照。

与之前简单的向前移动分支指针不同，这一次Git会基于三方合并的结果创建新的快照，然后再创建一个提交指向新建的快照。这个提交叫做合并提交合并提交的特殊性在于，它拥有不止一个父提交

$ git log --oneline --decorate --graph --all
*   9a219d6 (HEAD -> master) Merge branch ‘mod-b‘
|| * 65f2937 (mod-b) 优化了模块B
| * b52c200 创建了模块B
* | 130f52e 修补了线上的问题
|/
* 5d55df0 先前的工作2
* 36228f1 先前的工作1