Git相关介绍

背景

搜狗输入法开发同学在近期将输入法代码整体迁移到了公司内部的Git服务器，方便多分支管理。迁移后，测试对开发代码如何拉分支、如何查看changelog、如何打包、如何进行持续集成测试等等工作就产生了一些问题，也希望能做到知己知彼更好的保证质量，所以在此，小编梳理了一下Git相关的信息供测试同学了解。

Git是什么，为什么从SVN迁移到Git？

Git就是一个免费托管开源代码的远程仓库，你可以理解它就是一个大型文件服务器，在上面放置了N多代码文件。同时，Git还有一个web页面，可以方便用户访问、操作代码。 很多关于 Git 的文章都会说 Git 是分布式的，比 SVN 那种集中式的管理更安全。还有一种说法是，可以在火车上 Commit 代码。 我的疑问是：SVN 之所以集中管理，一定程度上是需要避免代码的冲突，而 Git 这种所谓的离线提交，等到联网 push 的时候不是也会冲突吗？从这个角度来看，离线与在线提交都会产生代码冲突，那为什么 Git 就好，SVN 就不好呢？ 1、git有强大的分支管理能力 分支是什么： 在 SVN这类的版本控制系统上，分支（branch）是一个完整的目录，且这个目录拥有完整的实际文件。如果工作成员想要开启新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来对系统模块进行安全检查测试的，那将会像传染病一样，你改一个分支，还得让其他人重新切分支重新下载，而且这些代码很可能对稳定版本还是具有破坏性的。 在Git上，每个工作成员可以任意在自己的本地版本库开启无限个分支。举例：当我想尝试破坏自己的程序（安检测试），并且想保留这些被修改的文件供日后使用，我可以开一个分支，做我喜欢的事。完全不需担心妨碍其他工作成员。只要我不合并及提交到主要版本库，没有一个工作成员会被影响。等到我不需要这个分支时，我只要把它从我的本地版本库删除即可，无痛无痒。 我可以在Git的任意一个提交点（commitpoint）开启分支！（其中一个方法是使用gitk –all 可观察整个提交记录，然后在任意点开分支。） 2、git是分布式的、支持离线工作

但是集中式的版本控制，有个严重的缺陷。就是中央服务器的单点故障。如果服务宕机一个小时，在这期间，没有任何人可以在正在工作的版本上很好的合作或者去保存某一个版本的改变。另外如果中央数据库的磁盘坏了，并且可能没有保存备份，那么将丢失所有的东西。你失去了绝对一切 - 除了单一的任何人的快照恰好有在本地计算机上项目的整个历史。当然本地的版本控制系统也有相同的问题。虽然，你能够把每个人的本地代码，进行合并得到一个相对完整的版本，但是当你把这个相对完整的版本重新部署到服务器的新仓库时，将会丢失所有的历史版本包括日志。

在Git 中的绝大多数操作都只需要访问本地文件和资源，不必联网就可以看到所有的历史版本记录，而SVN 却需要联网。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快，但我们需要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展示给你看。如果想要看当前版本的文件和一个月前的版本之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算。 SVN 断开网络或者断开V**就无法commit代码，但是Git 可以先commit到本地仓库。用SVN的话，没有网络或者断开V**时，你当然也可以继续在本地开发，但是无法commit代码，因为SVN 每次commit都必须联网，长时间不commit代码会丢失大量开发进程的历史纪录。有个比喻是：不能commit就像用word写文档不能save一样危险。而且有网络的情况下每一次commit都会花上数秒甚至更长时间。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，因为是在本地仓库commit所以几乎不需要时间，而且commit一定要频繁，不然无法记录你的改动，如果你一天commit一次，中间的修改你就找不回来，然后等到了有网络的时候再将版本纪录和代码一起上传到远程仓库。 Git 的内容完整性要优于SVN。因为Git 在commit（存储在本地）或者push（上传到远程仓库）之前，通过对文件的内容或目录的结构计算出一个 SHA-1哈希值，作为指纹字符串进行内容的校验，并将此结果作为数据的唯一标识和索引，在远处仓库接受到commit的文件之后，会再计算一遍哈希值然后跟传递过来的哈希值做比较，如果不一致，说明文件在传输时变得不完整，或者磁盘损坏导致文件数据损坏。另外在 Git 数据库中的东西都是用此哈希值来作索引，而不是靠文件名。 3、git更快 Git 克隆一个完整项目的速度非常快，SVN 非常慢。我们以克隆一份拥有五个分支的完整项目以及版本库来说，SVN是同时复制5个版本的文件,也就是说重复五次同样的动作。而Git 只是获取文件的每个版本的元素，然后只载入主要的分支(master)在我的经验，克隆一个拥有将近一万个提交(commit)，五个分支，每个分支有大约1500个文件的 SVN，耗了将近一个小时！而Git只用了区区的1分钟。 4、git 的缺点 Git 没有严格的权限管理控制，一般通过系统设置文件读写权限的方式来做权限控制; 工作目录只能是整个项目。比如 checkout，建分支，都是基于整个项目的。而 svn 可以基于项目中的某一个目录;代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

Gerrit又是什么？

https://git.XXX.com/XXXX Git远程仓库，用来备份输入法代码，一般不对这个仓库进行操作。 http://gerrit.XXX.com Gerrit是一个免费、开放源代码的代码审查软件。利用网页浏览器，同一个团队的软件程序员，可以相互审阅彼此修改后的程序代码，决定是否能够提交，退回或者继续修改。Gerrit 是使用 Git 作为底层版本控制系统，通过网页界面，能方便的做代码审核工作的一个轻量型框架，出自google团队的开源项目。其主要功能就是用来做Code Review。可以用自己的公司账号登录，开发负责加相关代码权限。Web页面，拦截push代码操作，实现代码Review，同时实现相关权限管理。

开发怎么用Git？

按照需求提出后的开发顺序一般分为以下几步： 一、开发拉分支 1.拉分支时机是什么？（原计划是上一条支线A上线后，在A支线基础上拉出，但目前迭代较快，不能实现在前一条支线完全上线后再拉取下一条支线进行开发。） Answer：如下图所示，V8.36在测试阶段，V8.37会基于V8.36集成测试后的版本拉分支，当V8.36上线后有bug修复，会有机制通知对应开发把修复bug代码Merge到V8.37功能分支上。

2.拉分支命令Git branch？有没有其他方法？拉好后如何通知其他开发拉功能分支？ Answer：目前大部分开发通过Android studio选到某一分支，通过New branch拉分支。

开发同学在新功能开发前会主动找开发负责人口头确认。 3.如果B开发的功能依赖A开发的功能，如何拉分支？ Answer：功能分支的拉取，都必须基于上一条发版分支拉取，即都基于上图的V8.36上拉分支，如果有依赖的函数，可以通过Merge来操作。不允许出现B功能从A功能支线上拉取分支的现象出现。 二、开发实现，提交代码 功能开发会先提交代码到本地仓库，然后提交到gerrit仓库等待代码review，通过Gerrit的权限控制不会把代码提交到远程Git仓库。 三、解决冲突，Merge/合并代码 1.解决冲突的时机？ Answer：必须在代码Merge到Gerrit的时候解冲突，比如push 语音分支代码 to V8.31分支的时候，会先拉取最新V8.31分支代码到本地，解决语音分支代码和V8.31代码的冲突后才可以提交代码到gerrit。 2.Merge代码到发版支线的时机是什么？令牌机制怎么生效的？（解决多个开发同时Merge代码会导致混乱的情况。） Answer： 令牌机制解释： ①测试完成后，会通过邮件通知开发哪些功能分支通过测试，可以进行Merge到发版分支的操作； ②开发负责人根据测试邮件，会通过打包系统的代码冻结功能，逐一开放对应开发Merge功能分支代码到发版分支的权限，类似令牌传递。

3.会不会存在开发随意/不小心merge到发版分支的情况？ Answer：不会。发版分支在测试阶段会冻结，直到测试通过进入到集成测试阶段后解冻。Merge只能在解除冻结后进行。 四、代码Review 1.Review是否强制执行？Review log可以看到吗？比如是不是每笔代码都经过了review。 Answer：Review机制强制执行，不review无法进gerrit。可以通过gerrit上的面板查看review log。以下是gerrit系统review面板截图：

五、打包（dailybuild包, 灰度包、正式版包、实验版包） 1.如何打包（测试包，灰度包，正式版包，实验包） Answer：均可通过打包系统自动打包。打包前需要进行相关配置，如下图所示：

六、bug修复 1.发现的Bug在什么支线修复？ Answer：功能测试阶段发现的Bug在功能支线上修复，合并功能支线之后在集成测试过程中发现的bug在合并后的分支上修复。 七、版本发布/上线后的支线操作 1.上线后，支线做什么处理？是否会冻结？ Answer：灰度期间不做冻结，方便开发修复Bug，在正式版发布后对发版支线进行冻结，并Merge代码到Master支线进行备份。 2.上线后发现bug怎么修复？ Answer：在发版分支上修复，并重新打包release分支进行发版。 3.如果发现历史bug，怎么在以前的支线上修复并Merge？ Answer：不需要在以前支线修复，在最新待发版的支线修复，可能在功能分支上，可能在发版分支上。

测试怎么用Git

怎么Clone和查看输入法代码？ 推荐Git GUI工具Source Tree：https://www.sourcetreeapp.com/ 公司的Gerrit仓库可以通过公司邮箱登录，所以在source Tree的授权过程中，也使用公司邮箱。（邮箱相关的权限需要申请。）

具体工具的使用大家可以自行搜索，在此不多赘述。

迁移时发现的问题

一、迁移是通过SVN的命令 SVN Git实现的，但是这个命令会自动排查空的文件夹并去除，影响到了输入法模块的逻辑。 解决方案：通过自动化脚本对比SVN和Git所有的代码文件并进行MD5check，对被过滤掉的文件进行测试，保证功能不受影响。 欢迎添加我们的搜狗测试微信号，与我们一起聊聊测试。