我勒个去,你怎么把这种问题代码提交到仓库啊??

码云Gitee
 码云Gitee
发布于 2018年05月11日
收藏 11

我已经疯了,今天公司新来的小白提交了好了问题代码到项目仓库,最要命的是项目在线上跑不起来时费劲好大力气,检查了各种可能性,甚至还一度怀疑是不是数据库、应用服务器有问题呢。花了半个小时才发现是代码问题,追踪到版本管理才发现是新来的小白提交了很多问题代码!!!

然后又花了很多时间为了把这个被小白污染的仓库清理干净,因为在他提交的前前后后都会其他的代码更新。

都怪我,为了着急上线没怎么做测试就匆匆上线;都怪我,没有检查大家提交的代码就急忙更新。业务中断两个小时,看来离滚蛋不远了。吃键盘的心都有了!!!

----- 华丽分割线 -----

这就是不做代码评审的下场!!!

可是代码评审很难搞,特别是使用 SVN 或者把 Git 当做 SVN 来用的团队。

我们希望项目的主仓库只有负责人才有权限操作,项目组成员对代码的任何修改都要经过审核后才能合并到主仓库。这样才能确保上述事故不会发生。

----- 呼啦啦分割线 -----

其实只要我们善用 Git 工作流就可以轻轻松松实现代码的评审功能。

以码云为例,基本流程如下:

  1. 假设项目主仓库 A/Project1 ,该仓库只有项目负责人(小红)具备写权限,项目成员只读

  2. 新来的小白复制 A/Project1 仓库到 "小白/Project1"  (在 A/Project1 页面点一下 Fork 按钮)

  3. 然后小白开始制造各种 Bug ,修改无数代码

  4. 写了一天的代码,小白觉得可以交差了,然后创建了个 Pull Request 请求把当前的改动合并到主仓库

  5. 项目负责人小红看到有人提交了 Pull Request ,打开小白修改的文件一看,惊呼:这是什么垃圾代码!!!

  6. 一时间,小白哭,小红怒,天色阴暗,可能要下雨了。。。


如果你还不熟悉 Git 工作流的操作,请前往 https://gitee.com/ 体验。

欲知后事如何,请听下回分解。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:我勒个去,你怎么把这种问题代码提交到仓库啊??
加载中

精彩评论

JPer
JPer
红薯写的BUG又给小白背锅 (<- _<-)
阿信sxq
阿信sxq
所以说上次删除Command类的构造器和set/get方法事件之后就总结出来这个?
银杏果果
银杏果果
git中直接还原为老版本先顶一下呗,干嘛非得线上中断修复bug后跑新版本呢?感觉这种做法本就不合理,不管是小白还是其它有经验的总有犯错的时候,不可能新版本有问题就中断线上服务等着bug修复吧。
沉默狮
沉默狮
企业内项目,fork后成了个人项目了呢,码云建议只在有意向改进项目时使用。看来我没get 到重点,小红~
久永
久永

引用来自“JPer”的评论

红薯写的BUG又给小白背锅 (<- _<-)
错!是小红写的!撰文请用代称。

最新评论(42

沉默狮
沉默狮

引用来自“沉默狮”的评论

企业内项目,fork后成了个人项目了呢,码云建议只在有意向改进项目时使用。看来我没get 到重点,小红~

引用来自“红薯”的评论

你真逗,你不让 fork 就不会成为个人项目了? 与其抵挡不住,不如公开透明用 fork 来协作。
现在保护分支非管理员只能提交Pull request合并请求很爽呀,不用fork了
tianyuliang
tianyuliang
又是那个小白要背锅了........................
凯撒大弚
凯撒大弚

引用来自“JPer”的评论

红薯写的BUG又给小白背锅 (<- _<-)

引用来自“久永”的评论

错!是小红写的!撰文请用代称。
红薯的红,没毛病
♂茶舞
♂茶舞
打丫的
terrence_tian
terrence_tian
建议你们使用git flow的工作流,不要用fork这种适合开源项目用的工作流。
阿昭
阿昭
代码没有回归测试就上线,还好意思虚构一个小白来顶包:laughing::laughing::laughing:
Linesh
Linesh
作为用惯了 git 的同学,看到标题的第一反应是:

* revert 一下有问题的提交,分分钟搞定
* bisect 调试一下哪个提交有问题,分分钟找到问题提交

不过并没玩过 svn,不知道模型是不是有些不一样。
penngo
penngo
因为j2cache,让红薯当上2018版本帝,现在推出git工作流功能,想把j2cache版本帝称号甩给小白。@红薯
返回顶部
顶部