0. 快速上手与理解

  • 如果你的团队来了一个新队员,有一台全新的机器,你们是否有一个文档,只要设置了相应的权限,她就可以根据文档,从头开始搭建环境,并成功地把最新、最稳定版本的软件编译出来,并运行必要的单元测试?(在这过程中,不需要和老队员做任何交流)

其实我们非常想说可以,但是最后在仔细考虑后发现确实是不可以的。我们的文档注重的方面更多地在理解用户需求与后端的设计上,但是关于配置环境,运行单元测试这方面的文档,虽然后端工程师在启程时写过一篇,如下:

但是后期并没有对它进行必要的完善与维护,并且没有将它push到github上,所以我们即使想说是,但是确实是不可以的。我们没有重视对于环境与运行方面的文档。

1. 你的团队的源代码控制在哪里?用的是什么系统?如何处理文件的锁定问题?

场景: 程序员果冻正在对几个文件进行修改,实现一个大的功能, 这时候,程序员小飞也要改其中一个文件,快速修复一个问题。怎么办?

一个代码文件被签出 (check out) 之后,另一个团队成员可以签出这个文件,并修改,然后签入么?

有几种设计,各有什么优缺点?

例如,签出文件后,此文件就加锁,别人无法签出;  或者, 所有人都可以自由签出文件

答:我们团队的源代码控制在Github上,使用的Git系统与Github本身集成的一些其他功能。

由于Git的特点,在处理文件的合并这方面有着易懂且优秀的合并技巧。

以下是场景分析:

程序员果冻现在正在对几个文件进行修改,程序员小飞要修改其中一个文件,修复一个大bug。果冻因为还没有修改完,还没有push。但是很快,小飞修改完成了,commit,push成功!小飞乐滋滋地想着自己即将到来的奖金,去吃饭了。办公室就剩下果冻一个人在紧张赶工….也是轻松且愉悦地commit,push。

啊?被拒绝了!

Pushing to git@github.com:buaase/Phylab-Web.git

To git@github.com:buaase/Phylab-Web.git

! [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值)

  • ==分割线上方是本地数据库的内容

  • ==分割线下方是远程数据库的某次产生冲突的commit所修改的内容。

这时候我们需要通过一双慧眼来识别哪些都可以保留,哪些保留远程数据库的内容,哪些保留本地数据库的内容。在将文件冲突的内容合并后,删除掉<<<<< 和=====,>>>>>这样的东西,重新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出错时,会自动通知我的邮箱(qianlxc@126.com)

【Beta阶段】团队源代码管理的更多相关文章

  1. 2016福州大学软件工程Beta阶段团队作业成绩汇总

    1.评分规则 本次Beta阶段团队作业评分方法如下: 团队得分=[[7次scrum过程评分+(小组互评得分+教师评分)/2]/2],其中过程.小组.教师各30分 说明:由于没有规定提交团队贡献比,因此 ...

  2. Beta阶段团队成员贡献分分配规则

    Beta阶段团队成员贡献分分配规则 Alpha阶段贡献分分配有些负责,在这里进行一些修改: 对任务完成得分部分进行了简化 对发现bug的惩罚措施进行了修改 移除了优化得分,不鼓励修改他人代码 移除了帮 ...

  3. [软工顶级理解组] Beta阶段团队贡献分评分

    贡献分评分依据 下述表格适用于前端.后端.爬虫开发者的评分,在此基础上进行增减. 类别 程度 加减分 准时性 提前完成 +0 按时完成 +0 延后完成,迟交时间一天内或未延误进度 -2 延后完成,迟交 ...

  4. Beta阶段团队项目开发篇章2

    例会时间: 2016.12.4 例会照片 个人工作 上阶段任务验收: 组员任务都已完成. 任务分配 组员 任务内容 韩慧敏 对调查问卷的结果进行分析和总结,确定Beta阶段各任务的优先级,撰写相关博客 ...

  5. Beta阶段团队项目开发篇章4

    例会时间 2016.12.11 例会照片 个人工作 上阶段任务验收 删除robot功能较为简单,基本实现,但是一直Question版块任务量过大,考虑到最近要进行编译课设第二次测试,为该任务再分配一段 ...

  6. Beta阶段团队项目开发篇章3

    例会时间 2016.12.6晚 例会照片 个人工作 上阶段任务验收 中英文切换功能已经实现,调查结果分析已经完成,博客基本撰写完成,在征求其他组员意见后发布.任务基本完成. 任务分配 组员 任务内容 ...

  7. Beta阶段团队项目开发篇章1

    例会时间:2016.12.1 例会照片: 个人工作: 任务分配: 组员 任务内容 李文涛 编写并发布调查问卷 姬索肇 审核并传播调查问卷 韩慧敏 审核并传播调查问卷 任务截止时间 2016.12.4 ...

  8. BugPhobia回顾篇章:团队Beta 阶段工作分析

    0x00:序言 1 universe, 9 planets, 204 countries,809 islands, 7 seas, and i had the privilege to meet yo ...

  9. BugPhobia团队篇章:团队管理与Github源代码管理说明

    0x00:序言 To the searching tags, you may well fall in love withhttp://xueba.nlsde.buaa.edu.cn/ 再见,无忧时光 ...

随机推荐

  1. hdu 2203 亲和串

    把T串扩展成两倍   然后KMP  注意T的长度要大于P的长度 #include <iostream> #include <cstdio> #include <cstri ...

  2. 多线程之ReentrantReadWriteLock

    java5以后在java.util.concurrent包下,有很多的并发类,可以让我们摆脱java5时,笨重的写法来满足多线程,而且提供了更加丰富的使用场景能力 其中,在locks包下,提供了 Re ...

  3. HTTP 错误 500.21 - Internal Server Error 处理程序“ExtensionlessUrlHandler-ISAPI-4.0_64bit”在其模块列表中有一个错误模块“IsapiModule” 解决方法

    IIS在发布网站后找不到首页,提示以上错误,原因是在“应用程序池”中,把对应的网站的“托管管道模式”设置为“集成”即可.

  4. vim 光标按行移动

    记录一下: [ H/M/L ] 注意:这几个命令是大写的. 使用H/M/L这三个键,可以让光标跳到当前窗口的顶部.中间.和底部,停留在第一个非空字符上.H命令和L命令前也可以加一个数字,但数字的含义不 ...

  5. 【原创】开源BI领袖-SpagoBI5.X最详细的中文版介绍

    SpagoBI是唯一100%的开源商业智能套件由 Engineering Group的SpagoBI实验室(www.eng.it)开发和管理.它提供了强大的分析能力,从传统的报表和图表功能到自助分析. ...

  6. 使用Xcode6.1.1打包出现Your account already has a valid iOS Distribution certificate问题

    1.问题描述: 使用客户证书在Xcode6.1.1上进行打包测试,出现如下问题,查看网上也很多类似错误且解决办法各异. 2.我的解决办法: 让客户将开发.发布证书重新revoke掉之后重新创新并给到p ...

  7. A little problem for pt-pmp

    https://bugs.launchpad.net/percona-toolkit/+bug/1320168 We use the pt-pmp (a variety for pmp !http:/ ...

  8. linux的文件种类与扩展名

    一.文件种类: 1.普通文件(regular file)第一个字符为[ - ] 包括:①纯文本档(ASCII):这是Linux系统中最多的一种文件类型,称为纯文本档.是因为内容为我们人类可以直接读到的 ...

  9. iOS8中使用CoreLocation定位[转]

    本文转自:http://blog.devzeng.com/blog/ios8-corelocation-framework.html iOS8以前使用CoreLocation定位 1.首先定义一个全局 ...

  10. Java分布式应用技术架构介绍

    分布式架构的演进 系统架构演化历程-初始阶段架构