0. 快速上手与理解
- 如果你的团队来了一个新队员,有一台全新的机器,你们是否有一个文档,只要设置了相应的权限,她就可以根据文档,从头开始搭建环境,并成功地把最新、最稳定版本的软件编译出来,并运行必要的单元测试?(在这过程中,不需要和老队员做任何交流)
其实我们非常想说可以,但是最后在仔细考虑后发现确实是不可以的。我们的文档注重的方面更多地在理解用户需求与后端的设计上,但是关于配置环境,运行单元测试这方面的文档,虽然后端工程师在启程时写过一篇,如下:
但是后期并没有对它进行必要的完善与维护,并且没有将它push到github上,所以我们即使想说是,但是确实是不可以的。我们没有重视对于环境与运行方面的文档。
1. 你的团队的源代码控制在哪里?用的是什么系统?如何处理文件的锁定问题?
场景: 程序员果冻正在对几个文件进行修改,实现一个大的功能, 这时候,程序员小飞也要改其中一个文件,快速修复一个问题。怎么办?
一个代码文件被签出 (check out) 之后,另一个团队成员可以签出这个文件,并修改,然后签入么?
有几种设计,各有什么优缺点?
例如,签出文件后,此文件就加锁,别人无法签出; 或者, 所有人都可以自由签出文件
答:我们团队的源代码控制在Github上,使用的Git系统与Github本身集成的一些其他功能。
由于Git的特点,在处理文件的合并这方面有着易懂且优秀的合并技巧。
以下是场景分析:
程序员果冻现在正在对几个文件进行修改,程序员小飞要修改其中一个文件,修复一个大bug。果冻因为还没有修改完,还没有push。但是很快,小飞修改完成了,commit,push成功!小飞乐滋滋地想着自己即将到来的奖金,去吃饭了。办公室就剩下果冻一个人在紧张赶工….也是轻松且愉悦地commit,push。
啊?被拒绝了!
! [rejected] master -> master (non-fast-forward)
果冻心里很是郁闷,难道就因为我长得没小飞帅,就要拒绝我的提交吗?
嘿嘿,其实不是的,其实这是因为果冻在进行push之前,小飞已经推送了内容到远程数据库,果冻的push就被拒绝。因为直接push会覆盖小飞所修改的内容。
所以作为项目经理的我,在跟我们团队的队员强调Git的使用时反复强调一点,在所有的push之前一定要进行pull,将服务器端他人推送的内容先合并到本地。
比如我们在项目中演示如下:
关于文件的锁定这一点上,git本身的合并机制支持了多个人同时开发不同的feature,不论是通过同一个分支,或者是不同的分支。如果在同样的时间内,一个文件只能被一个人修改的话,虽然是不会产生冲突,但是在某些项目里,这样类串行化的作业方式效率较低。当然在实际使用git的过程中应该尽量避免冲突,能够自动merge就自动合并。
2. 如何看到这个文件和之前版本的差异? 如何看到代码修改和工作项 (work item),缺陷修复 (bug fix) 的关系。
场景: 程序员果冻看到某个文件被修改了,他怎么看到这个文件在最近的修改究竟改了哪些地方?
场景: 程序员果冻看到某个文件在最新版本被改动了100 多行, 那么和这100多行对应的其他修改在什么文件中呢? 这个修改是为了解决哪些问题而作的呢? 那些问题有工作项 (work item,issue),或者bug 来跟踪么?
答: 在git管理中, 使用git diff即可看到文件和之前版本的差异。
-
git diff:是查看working tree(工作目录)与index file(暂存区)的差别的。
-
git diff --cached:是查看index file(暂存区)与commit(本地仓库)的差别的。
-
git diff HEAD:是查看working tree(工作目录)和commit(本地仓库)的差别的。
在git里,这三个概念是很重要的,其中 git add的一个功能是将修改从工作目录添加到index file,commit的工能就是从index file的修改添加到 commit。
比如下面这是一个截图:(使用git diff --cached)
当我们把a.txt文件提交并作出修改后,可以使用git diff来查看差异:
在Github中,也可以通过可视化的界面来看到每次修改的代码(包括增加,删除)文件与修改的具体位置,修改的具体内容。
比如下面这样的界面:
可以看到每次修改的文件路径、文件的内容、红色代表删除掉的内容,绿色代表添加的内容
修改为了解决的问题要通过commit日志的提交信息来实现,但是很遗憾,在我们的团队项目中,关闭Issue和commit日志信息都做得不太好。大家的commit日志除了黄雨萌和我的相对规范一些,队员们很多都用来当打油诗了…
一次commit可以和Issue相关联,以表明这个Issue是由本次commit修复的,只需要在git commit的时候使用时加入如下commit日志信息即可:
-
fix #xxx
-
fixes #xxx
-
fixed #xxx
-
close #xxx
-
closes #xxx
-
closed #xxx
比如我使用了如下语句:
现在可以在github看到
可以看到最后那里,一次commit和issue的关闭是绑定的。
3. 如果某个文件在你签出之后已经被别人修改,并且签入了,那么你在签入你的修改的时候, 如何合并不同的修改(merge)? 你用了什么工具来帮助你?
答: 我们使用Git来帮助我们完成了这件事。
在一般情况下,git pull后git会自动合并Git修改的部分,自动的Merge。但是,也存在无法自动合并的情况。就像果冻和小飞这样,远程数据库和本地数据库的同一个地方都发生了修改的情况下,因为Git无法自动判断要选用哪一个修改,所以就会发生冲突。但是,Git会在发生冲突的地方打个标记!比如这样式的:
<<<<<<< HEAD
test in Local
=======
test in Remote
>>>>>>> 17c805…(Commit的Hash值)
这时候我们需要通过一双慧眼来识别哪些都可以保留,哪些保留远程数据库的内容,哪些保留本地数据库的内容。在将文件冲突的内容合并后,删除掉<<<<< 和=====,>>>>>这样的东西,重新add,commit,push,即完成了一次手工合并。
不过因为大家都是新手入门,不太会合理地人工合并冲突,所以项目经理本身在分配任务时,遵循了一个原则:尽量不让两个人的任务在同一个文件上产生重叠。
每个人修改的文件范围或者其他都是固定的,一般不会存在两个人同时修改同样的文件。当然,前端和后端在修改时大部分时候都会产生冲突,这时候我们就使用了另一套机制来帮我们实现这一点:
新建分支与分支合并。
Beta阶段,我们要用到一个论坛的框架与现有的一些逻辑,但是又要同时兼容之前的网站主页的风格与设计,为了实现这一点,我们的前端负责修改页面样式,后端负责对接后台逻辑与数据库的同步问题。那么问题来了,如果两个人在同一个分支下进行工作,那么每次都要有合并与修改记录,并且如果一个人修改的部分因为某些bug不可用的时候,另一部分也无法确认其所修改的部分是否正确。所以我们建立了两个分支(Back-end和Front-end),Front-end上只有一个wecenter的模版供前端进行样式的修改,而后端使用默认的wecenter的模版进行数据库的对接与其他工作,两份工作由此而开始独立进行,互不干扰。
我们团队项目里的Front-end分支和Back-end分支的情况如下:
等到前端做到可行的程度后,前后端修改的部分开始合并,合并两个分支来将前端修改的部分合并到Back-end分支上,这样合并的工作只在一天进行,且由于冲突的部分较少,大部分都是自动合并,效率很高。
4. 你有20个文件都是关于同一个功能的修改,你要如何保证这些文件都同时签入成功(修改的原子性),或者同时签入不成功?
场景: 程序员果冻要签入 20 个文件,他一个一个地签入, 在签入完5 个 .h 文件之后, 他发现一些 .cpp 文件和最新的版本有冲突,他正在花时间琢磨如何合并... 这时候, 程序员小飞从客户端同步了所有最新代码, 开始编译, 但是编译不成功 - 因为有不同步的 .h 文件和 .cpp 文件! 这时候, 别的程序员也来抱怨同样的问题,果冻应该怎么办?
答:果冻目前面临的问题恰恰可以由我们第三点所述的branch的好处解决。
Branch的出现,可以让任何一位开发者基于其他人的代码或环境都完整可用(即stable版)的环境下进行自己的部分的独立开发 。
最后的合并工作可以放在一天之内,将所有的Branch上的feature合并到一个dev分支上来。但是这样面临的风险也是有的,多个分支同时合并时如果出现了比较大的冲突,合并起来必须小心翼翼。
同时,在解决一个Issue的时候,也可以新建一个Issue分支,比如像如下所示:
在解决了Issue后,可以使用分支合并的技术将两个或多个分支合并。
5. 你的PC 上有关于三个功能的修改,但是都没有完成,有很多文件处于半完工的状态,这时你要紧急修改一个新的 bug,如何把本地修改放一边,保证在干净的环境中修改这个 bug, 并成功地签入你的修改 --- changelist management。
答:在Git里,不能完整地保证commit后整个环境处于可编译或可运行状态下的commit是不好的提交。
所以在文件半完工的状态下,我们不可以使用commit来将文件修改的内容留下来。
Git为我们提供了一种类似于操作系统里的保存现场的指令,那就是stash。 它可以把当前工作现场"储藏"起来,等以后恢复现场后继续工作,使用方法类似下面:
$ git stash
Saved working directory and index state WIP on master: 5655bdc Merge branch 'mas
ter' of https://github.com/buaase/Phylab-Web
HEAD is now at 5655bdc Merge branch 'master' of https://github.com/buaase/Phylab
-Web
这时候就会发现,add了以后的东西都被"雪藏"起来,现在的工作区非常干净,我们这时候可以在一个干净的环境中修复紧急的bug并提交,签入,在push后,再使用
git stash apply 或者 git stash pop
来将保存起来的内容取出来继续开开心心地开发啦。
比如下面我们来实际操作演示一下
可以看到我们对a.txt进行了修改,下面我们使用stash指令来让它”保存现场“
可以看到实际上 git stash后,我们对于a.txt的修改不见了?!
再使用 git stash pop,再来一观:
可以看到 git stash pop 后,对a.txt的修改又回来了。
6. 如何给你的源代码建立分支?
场景:你们需要做一个演示,所以在演示版本的分支中对各处的代码做了一个临时的修改,同时,主要的分支还保持原来的计划开发。你们怎么做到的?在演示之后,演示版本的有些修改应该合并到主分支中,有些则不用,你们是怎么做到的?
场景:你们的软件发布了,有很多用户,一天,一个用户报告了一个问题,但是他们是用某个老版本,而且没有条件更新到最新版本。这时候,你如何在本地构建一个老版本的软件,并试图重现那个问题?
给源代码建立分支的过程我们下面使用一个gif图来演示一下:
上面这个gif图演示了我们使用cherry pick的一个完整流程(第一次录制gif见谅)
主要流程是我们建立了两个分支 dev1和devtest分支,并使用cherry-pick将dev1上的commit(日志信息为"test")合并到devtest分支上来,并且最后造成devtest分支也有该commit提交。
并且在这过程中通过命令行建立了远程分支。
当用户没有条件更新到新版本的时候,我们将新建一个分支,然后使用git reset hashcode(commit日志的唯一hash码,可以倒退回过去),然后进行测试以重现问题。
全过程如下所示:
我们可以看到,我们从fixed #189的HEAD 回退到了 b5320c所代表的commit记录处。
7. 一个源文件,如何知道它的每一行都是什么时候签入的,为了什么目的签入的 (解决了哪个任务,或者哪个bug)?
场景:一个重要的软件忽然出现崩溃的情况, 程序员果冻经过各种debug手段,发现问题是在某一个文件中有一行代码似乎显然出了问题,但是这个模块被很多其他模块调用,这行代码是什么时候,为了什么目的,经过谁签入的呢?如果贸然修改,会不会导致其他问题呢?怎么办?
答:针对一个源文件的每一行是在什么时候签入,为了什么签入,在github里有非常好的支持,如下图:
在上图中我们可以看到,Handle10611.tex在两次提交中被修改了,分别是在65b4fe1和9a9913d两次commit中被修改过,并且两次都带有比较清晰的commit日志,知道它是为何被签入,修改又是为了什么。以及所有跟它有关的所有commit提交信息。
一个良好的团队应当维护一个良好的commit日志,并且有所规范,但是我们组在这一点上还非常欠缺...
8. 如何给一个系统的所有源文件都打上标签,这样别人可以同步所有有这个标签的文件版本?
代码每天都在变,有时质量变好,有时变差,我们需要一个 Last Known Good (最后稳定的好版本) 版本,这样新员工就可以同步这个版本,我们如果需要发布,也是从这个版本开始。那么如何标记这个 Last Known Good 版本呢?
使用git来打tag这件事,在Github中是可以很方便来做这件事:
每次发布到一定成果后,就需要发布一个realease版本,但是这样的话,是对commit本身打标签。在git里,标签分为两种类型:轻量标签和附注标签。轻量标签是指向提交对象的引用,附注标签则是仓库中的一个独立对象。
$ git tag v1.0.0
想查看tag的话,可以使用git tag来查看,如下:
如果想回到某个标签时某个文件的状态,那么只要使用git checkout tag(标签名) 即可,如下面这个gif所示:
可以看到我们的项目在发布时一共发布了1.1.0,1.1.1,1.0.0三版。
9. 你的项目的源代码和测试这些代码的单元测试,以及其他测试脚本都是放在一起的么? 修改源代码会确保相应的测试也更新么?你的团队是否能部署自动构建的任务?
在签入之前,程序员能否自动在自己的机器上运行自动测试,以保证本地修改不会影响整个软件的质量?
在程序员提交签入之后,服务器上是否有自动测试程序,完成编译,测试,如果成功,就签入,否则,就取消签入?
团队是否配置了服务器,它自动同步所有文件,自动构建,自动运行相关的单元测试,碰到错误能自动发邮件给团队
答:配置了服务器,一开始使用的是Travis-CI来自动集成测试,但是由于网络因素,Travis-CI登录很慢,所以最后决意采用了drone.io来进行自动化的单元测试,每次测试都会自动按照预定的脚本运行单元测试,单元测试通过以后可以在Github的ReadMe里体现出来。
是这样的标志:
点开build passing的示例,我们可以看到在drone.io中我们部署的自动化测试:
每一次commit都会触发自动化测试,在部署成功后(只针对master分支),已经test了38次。
在Setting中也可以看到,我们在build出错时,会自动通知我的邮箱([email protected])