git深入理解(九)：git分支管理与应用

此处以github平台为例。

branch

查看分支的情况&＃xff0c;前面带*号的就是当前分支
git branch

创建分支
git branch 分支名

删除分支
git branch -d 分支名

checkout

切换当前分支到指定分支
git checkout 分支名

创建分支并切换到创建的分支
git checkout -b 分支名

merge

合并某分支的内容到当前分支
git merge 分支名

如果两个分支同时进行了同一个文件的修改和提交&＃xff0c;在merge时就会产生冲突&＃xff0c;首先要手动打开文件解决冲突&＃xff0c;再提交。

查看分支合并图
git log --graph

红色和绿色的虚线分别代表两个分支。

git merge 的原理&＃xff1a;
我们知道分支文件中存储的是当前分支的最新一次提交的commitID&＃xff0c;也就是版本号&＃xff0c;而每一个版本号对应的 objects 文件中都存储着 parent 版本号&＃xff08;首次提交没有 parent&＃xff09;&＃xff0c;以此将版本串起来&＃xff0c;每一个分支都有自己的串。

比如将分支A合并到分支B&＃xff0c;其实就意味着使分支B和分支A的内容完全一致&＃xff0c;那么要达到这个目的最快的方式就是将分支A中的最新的commitID复制到分支B的文件中&＃xff0c;这样分支B也就拥有了分支A的串&＃xff0c;就达到了合并的效果。

如果在合并的时候出现了冲突&＃xff0c;需要手动编辑解决冲突&＃xff0c;然后提交一个commit&＃xff0c;但是分支A上还是之前的内容。

创建 b2 分支
git checkout -b b2
修改 t1.txt 文件&＃xff0c;并提交回到 master 分支&＃xff0c;修改 t1.txt&＃xff0c;并提交分别查看 log
$ git log -3 --pretty&＃61;oneline
2a09fbe5794df384dab0cf0a95751a969a5ae057 (HEAD -> master) yy
4052f8d1f053d8b486673b5e1c79c3720ff2316f del
0d3d0d430b2fb9f5788cde925319f718eaddd61d add$ git log b2 -3 --pretty&＃61;oneline
837a61a1e32de4bf25ced7ff6b8dc2820968100c (b2) xx
4052f8d1f053d8b486673b5e1c79c3720ff2316f del
0d3d0d430b2fb9f5788cde925319f718eaddd61d add可见是在 4052f8d1f053d8b486673b5e1c79c3720ff2316f 时产生的分支&＃xff0c;之后各自有一个提交。试图将 b2 合并到 master
$ git merge b2
Auto-merging t1.txt
CONFLICT (content): Merge conflict in t1.txt
Automatic merge failed; fix conflicts and then commit the result.手动修复 master 冲突文件&＃xff0c;然后提交
$ git add .
$ git commit -m &＃39;fix&＃39;
[master 19bf978] fix再次查看 log
$ git log -3 --pretty&＃61;oneline
19bf97852267733011f5f4bf5793d4a22224f71b (HEAD -> master) fix
2a09fbe5794df384dab0cf0a95751a969a5ae057 yy
837a61a1e32de4bf25ced7ff6b8dc2820968100c (b2) xx$ git log b2 -3 --pretty&＃61;oneline
837a61a1e32de4bf25ced7ff6b8dc2820968100c (b2) xx
4052f8d1f053d8b486673b5e1c79c3720ff2316f del
0d3d0d430b2fb9f5788cde925319f718eaddd61d add可以看到分支 b2 并没有什么变化&＃xff0c;而分支 master 变化较大&＃xff0c;首先 b2 的 837a61a1e3 插入到了 master 的 2a09fbe579 的前面去了
&＃xff08;那是因为 b2 比 master 先提交的&＃xff09;&＃xff1b;其次 master 多出了一个新提交 19bf978522。此时&＃xff0c;对于 b2&＃xff0c;如果不需要了则可以删掉这个本地分支&＃xff1b;如果还有用那么就应该使 b2 同步&＃xff0c;防止以后出现差错。
$ git checkout b2
$ git merge master
Updating 837a61a..19bf978
Fast-forwardt1.txt | 2 &＃43;-1 file changed, 1 insertion(&＃43;), 1 deletion(-)将 master 同步到 b2&＃xff0c;并不会有冲突发生&＃xff0c;那是因为 master 最新的提交晚于 b2 最新的提交&＃xff0c;Git 认为可以直接覆盖。所以&＃xff0c;当你准备
将“早期”代码合并到“晚期”代码中时才可能出现冲突&＃xff0c;反之则不会。最后再查看一次 log
$ git log master -6 --pretty&＃61;oneline
19bf97852267733011f5f4bf5793d4a22224f71b (HEAD -> b2, master) fix
2a09fbe5794df384dab0cf0a95751a969a5ae057 yy
837a61a1e32de4bf25ced7ff6b8dc2820968100c xx
4052f8d1f053d8b486673b5e1c79c3720ff2316f del
0d3d0d430b2fb9f5788cde925319f718eaddd61d add
71243b890c66751d8b32d547f0a0f6150775903c rm$ git log b2 -6 --pretty&＃61;oneline
19bf97852267733011f5f4bf5793d4a22224f71b (HEAD -> b2, master) fix
2a09fbe5794df384dab0cf0a95751a969a5ae057 yy
837a61a1e32de4bf25ced7ff6b8dc2820968100c xx
4052f8d1f053d8b486673b5e1c79c3720ff2316f del
0d3d0d430b2fb9f5788cde925319f718eaddd61d add
71243b890c66751d8b32d547f0a0f6150775903c rm


默认情况下Git会使用Fast-forward的方式来merge&＃xff0c;这样的好处是快&＃xff0c;当然也有不好的地方&＃xff0c;比如

$ git log master -5 --pretty&＃61;oneline
f3e1527aa1b7a44d4a34efcd15cbe48f3148ed1e (HEAD -> master) qqq
4a573a96f86a404fe22745ffd71c5341f636438d (b5) 555
fd0ef1ad99851b0871b6544eab1c5dd051c63882 444
069ec4544846898724d7c8cf8de6f8e0dcaaf408 merge from b3
31d8a05af468dc14dd5d1cfbdd8e8b6ca3b3db0b 333现在你可以清楚的看到 555 是从 b5 merge 来的&＃xff0c;但是如果我把 b5 分支删掉了
$ git branch -d b5
Deleted branch b5 (was 4a573a9).再次查看&＃xff0c;你就不知道 555 是来自 merge&＃xff0c;因此 fast-forward 模式会丢掉分支信息。
$ git log master -5 --pretty&＃61;oneline
f3e1527aa1b7a44d4a34efcd15cbe48f3148ed1e (HEAD -> master) qqq
4a573a96f86a404fe22745ffd71c5341f636438d 555
fd0ef1ad99851b0871b6544eab1c5dd051c63882 444
069ec4544846898724d7c8cf8de6f8e0dcaaf408 merge from b3
31d8a05af468dc14dd5d1cfbdd8e8b6ca3b3db0b 333鉴于此&＃xff0c;在 merge 的时候加上 --no-ff 参数即可避免掉这个问题&＃xff0c;他会产生一个新的commit。
$ git merge --no-ff b3 -m &＃39;merge from b3&＃39;

操作示例

当前目录有 aaa.txt, bbb.txt &＃xff0c;且是干净状态。
当前为master分支。

创建分支
git branch test-branch

切换分支
git checkout test-branch

当前目录具有和master分支一样的结构&＃xff0c;可见 test-branch 分支会继承当时创建它的分支的状态。

编辑文件
vi ccc.txt
提交
git add .
git commit -m ‘add ccc’
该分支第一次提交
git push -u origin test-branch
在Gitlab服务器查看我们推送的分支&＃xff0c;它会自动创建分支 test-branch

此时 test-branch 分支有ccc.txt文件&＃xff0c;而master分支是没有的。

切换到master
git checkout master

目录下没有ccc.txt文件。

合并 test-branch 分支到master分支&＃xff0c;首先要pull到最新版本。
git pull origin master
git merge test-branch
git push origin master
在Gitlab服务器查看master

删除所创建的分支
git push origin --delete test-branch
git branch
发现 test-branch 依然存在本地&＃xff0c;而远程仓库不存在此分支了。
git branch -d test-branch
git branch
发现 test-branch 已经不存在了

可见git的多分支是共用一个working copy&＃xff0c;当前是那个分支就显示那个分支的内容。

push到线上

将新建的分支以及分支代码提交到线上&＃xff0c;第一次Push的时候&＃xff0c;需要将本地分支和远端origin绑定&＃xff0c;使用it push origin test_branch -u&＃xff0c;这样远端会新建一个分支并接受此次提交。后面再提交就只需要git push即可

测试合并冲突

git branch test-branch
git checkout test-branch
git push -u origin test-branch
修改ccc.txt文件
git add .
git commit -m ‘modify ccc 2’
git push origin test-branch
git checkout master
修改ccc.txt文件
git status
git merge test-branch

error: Your local changes to the following files would be overwritten by merge:ccc.txtPlease commit your changes or stash them before you merge.Aborting


显然&＃xff0c;如果有改动未提交&＃xff0c;是不让merge的。
git add .
git commit -m ‘modify ccc 3’
git merge test-branch

Auto-merging ccc.txtCONFLICT (content): Merge conflict in ccc.txtAutomatic merge failed; fix conflicts and then commit the result


此时test-branch分支已经合并过来了&＃xff0c;只是出现了冲突&＃xff0c;打开ccc.txt解决冲突内容&＃xff0c;然后提交。
git add .
git commit -m ‘resolve conflict’
git push origin master
git status
git log --graph

之前svn解决玩冲突还需要执行resolved命令&＃xff0c;而git则不需要&＃xff0c;直接提交即可。

多人开发分支设计

master developtestingtask1task2


master 主干&＃xff0c;线上处于此分支&＃xff0c;有权限控制
develop 过度分支
testing 测试专用分支
task1 任务1
task2 任务1

1、管理员在master分支创建develop&＃xff0c;并负责将develop合并到master。

2、开发的时候在develop分支创建task1&＃xff0c;在task1中开发&＃xff0c;将task1合并到develop&＃xff0c;为了减少冲突应经常将develop合并到task1&＃xff0c;将task1合并到develop操作。

3、测试的时候去到测试服务器将develop合并到testing。

4、发布的时候去到线上服务器将develop合并到master。

如何修复线上Bug

比如你正在 task1 上开发一个功能&＃xff0c;而且开发了一段时间了&＃xff0c;这个时候突然线上报出一个bug&＃xff0c;你需要立即修复&＃xff0c;这个时候应该先保护好现场&＃xff08;使用 git stash 命令&＃xff09;&＃xff0c;不然切换分支后你的心该滴血了&＃xff1b;然后从 master 创建一个分支bug-100&＃xff0c;为什么不能从 develop 创建呢&＃xff1f;因为在多人开发模式下 develop 分支上经常会有一些暂时不需要同步到 master 上的提交。

修复好之后将分支 bug-100 的提交 merge 到 master &＃xff08;加上 --no-ff 参数&＃xff09;&＃xff0c;然后发布到线上&＃xff0c;删除 bug-100 分支。

总感觉哪里还少了点啥&＃xff0c;是的&＃xff0c;你的 develop 分支上同样存在这个bug&＃xff0c;而且我是在 bug-100 分支上修复的&＃xff0c;不是在 task1 分支&＃xff0c;所以如果不修复之&＃xff0c;日后将 develop 上的提交同步到 master 上的时候是不是会把这个 bug 也带过去了呢&＃xff1f;

既然如此&＃xff0c;有人会说&＃xff0c;这还不简单&＃xff0c;将 master 同步到 develop 不就行了。显然不能这么干&＃xff0c;因为 develop 上面还有一些提交没有同步到 master &＃xff0c;开头就提到过&＃xff0c;这样做将会是一场悲剧。 又有人说了&＃xff0c;那我在 develop 分支再重复修复一遍总行吧&＃xff0c;这个当然可以。不过 Git 专门提供了一个cherry-pick命令&＃xff0c;让我们能复制一个特定的提交到当前分支&＃xff1a;git cherry-pick commitID并且 Git 会替当前分支做一次提交。

此时就可以回到 task1 分支上&＃xff0c;恢复之前保存的现场&＃xff0c;并且要从 develop 同步一次&＃xff0c;然后接着开发了。

关于 git stash 命令可以参考 https://blog.csdn.net/raoxiaoya/article/details/111456361