上一篇文章其实写到一半, 因为很多操作没法在我刚创建的代码仓库上进行演示, 我得弄一堆分支或者commit. 这篇先把上一篇没有讲解的操作补全.

2020-12-12

VS2019 16.8更新了团队资源管理器, 如果你用的VS的团队资源管理器没有以下的Git功能界面, 请参考这篇文章 VS2019 16.8 “消失“的团队资源管理器

准备

本来这篇想以opencv的仓库为例子来进行演示, 但是我Clone了一下发现速度只有几十k. 所以还是想解决下这个Github的Clone速度问题.

如果在取消Clone以后VS是这样一直在取消中:

那么就去任务管理器中把所有的Git for windows给结束掉:

结束后会有以下的提示:

这个没什么问题, 感觉是VS陷入了死锁了. 任何和Git相关的操作导致VS一直在读条的, 都可以通过这个方式去中断Git操作.

Github加速插件

我用的是这个插件:

在Chrome的网上应用中搜索Github加速就行. 如果不是Chrome的话, 就在这个网址去搜索对应的代码仓库:https://github.com.cnpmjs.org/search?q=opencv

安装好了以后, Github的页面会增加一个接口:

这种属于镜像Clone. 概念就是国内访问Github的服务器AWS云很慢, 它就定期从Github的服务器上把数据下载到一个国内访问速度较快的服务器. 优点肯定是速度很快, 但是缺点也有, 这里Clone下来的仓库和Github之间会有时间差. 比如你Clone好了以后, 有人在Github上提交了一个bug修复, 你在当前的镜像地址是没法及时获取到这次提交的. 解决的方法也有, 下面我们先把Opencv的仓库Clone下来, 再来讲怎么解决这个问题.

这个镜像下载的速度真的是非常快了, 大概有几M每秒的速度:

回到上面的问题, 怎么把仓库改回GitHub上? 在Clone好了以后我们把仓库的地址还原为Github的地址, 并且同步一下:

把下面这两个地址改为Github的Clone地址:

这个才是官方地址:

改好以后, 记得同步一次:

出现红框的内容就表示同步成功了, 这时候你这个镜像仓库就回到了Github的主线上. 注意这里是和Github在同步,所以网速也会很慢, 但是由于数据量少很多, 所以还能接受.

下面检查下是否同步完成:

Git操作示范

查看Commit历史

如上图所示, 在分支下可以右键某个分支点击查看历史纪录:

仔细看下历史记录界面:

由于opencv分支实在太少, 看不出分支号标签的好处.如果像我们公司一样有很多分支在同时开发, 最终合并到主版本上. 在这里就可以很清晰的看出哪里是从哪个分支提交过来的代码.

查看某个文件的提交历史

首先要在解决方案资源管理器下:

右键选中某个文件或者文件夹:

点击查看历史记录后就会显示当前文件或文件夹相关的提交:

这个筛选功能非常实用.

切换到某个Tag上

Tag标签是开发者发版用的. 当这个版本需要Release给公众使用的时候, 我们会打上一个标签用来记录当前的Commit Id. 这是为了在这次发版后可以根据客户反馈的bug信息而找到对应的代码来debug.

目前Opencv发布的最新版本是4.3.0, 那我们就切换到这个版本.

在Tag内切换

在标记下找到对应的Tag 4.3.0:

右键这个tag:

签出一般用于分支, 我感觉不大适合tag. 我这里签出也报错了, 感觉还是4.3.0只是tag 并没有分支,所以VS执行签出的时候出现空指针错误.

一般的使用新建本地分支位置:

这里的签出分支是可以的, 因为是VS先根据4.3.0的tag创建一个分支4.3.1, 然后签出这个分支. 如果没有勾选这个, 那创建分支后你依然停留在原来的分支上, 需要自己在分支界面手动切换过去.

在历史记录内切换

下面是操作示范:

首先搜索4.3.0以后出现的一个commit右边有个绿色的符号4.3.0, 这个绿色标记就是Tag的标志. 说明这个commit对应的就是4.3.0的这个版本. 找到这个commit后有两种方式切换过去, 一种像上面一样用重置:

这两个选项很好理解, 就是你当前的修改代码要不要保留. 当重置以后, 在你当前的分支上把代码重置到这个commit. 这种方式不大推荐使用, 因为没法从一个分支的中间开发, 你的提交内容很可能和后面没有更新的提交冲突. 你可以看看当前分支的历史记录,有多少没有更新到本地的提交:

这里表示你当前没有更新的commit:

你在这个状态下提交的东西都有可能和上面的commit冲突. 这种方式适合把代码切过来编译对应版本的SDK, 不做任何开发操作.

还有一种是在这个commit的基础上创建新的分支, 这种方式比较推荐:

这种方式最适合你在这个Tag上进行bug修复, 然后发布新的修复子版本. 比如 4.3.1.

挑选Commit到当前分支

这个操作又叫cherry-pick. 顺着上面的情景, Opencv4.3.0发版了, 客户报了一个bug, 恰好这个bug在发版后修复了. 版本在外, 有大量客户在使用, 我们只会发布小的更新版本来修复某些问题, 而不是把4.3.0更新到master最新commit. 所以这个需求就是我当前的分支只需要其他分支的一些commit内容, 并不需要把两个分支给合并.

假设我们当前的分支是my_4.3.0, 同时在master分支上找到了一个我们需要的commit: