标签:模块 hang line create -o 不包含 ++ http 不同的
现在我们模拟一个简单的分支和合并案例,其中工作流可供真实项目借鉴。
(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
标签:模块 hang line create -o 不包含 ++ http 不同的
原文地址:https://www.cnblogs.com/velscode/p/10597417.html