# task76a4

**Repository Path**: ql_shinian/task76a4

## Basic Information

- **Project Name**: task76a4
- **Description**: No description available
- **Primary Language**: Python
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2016-05-19
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

#task76a4


很多时候1个大型项目在开发阶段，往往会涉及到数十名工程师，每周上百次的commit。
虽然会引入codereview但是还是很难避免有bug的代码被合并到master分支。

因此单元测试就变得非常重要了。

拿大型的java项目举例
java的junit可以完美配合项目构建工具maven，在每次部署前进行mvn test，来保证大型项目的项目质量。

当单元测试fail的时候，往往就可以通过fail的提示来codereview的找到出错的代码。
再通过git blame来确定该行代码是由哪位工程师提交的。进而找到相应的负责人去做bugfix。

但是当项目非常巨大并且复杂，一个一个版本的code review的效率是十分低下的。

我们需要一个更好的方式去定位从哪个版本开始，由哪个工程师的commit导致了错误。

如果项目是svn进行的版本管理，这个过程会非常痛苦。只能一个一个版本checkout下来，并执行单元测试。

如果是用git管理的，那当然会省心很多啦！


这里有1个由无数python高级工程师维护的巨型python项目，经历了10000次commit。

项目地址: [http://git.oschina.net/ql_shinian/task76a4](http://git.oschina.net/ql_shinian/task76a4)

很不幸的是，master分支上最新的代码并不能顺利通过unit.py的单元测试（`python unit.py`）。
你需要找到一个最近的能通过unit.py单元测试的版本，并进而知道谁是第一个引入bug导致unit.py失败的工程师。

本题的答案是该工程师的username。