公司统计代码行数的逆天逻辑

[sqfphoenix]

之前发了个帖子吐槽公司统计代码行数 前情提要

经过我两个月的奋斗，各种水行数，甚至突破自己底线贴工具类到代码里面，发现怎么都比不过别人的代码行数，今天才发现，原来公司统计是会把 merge 提交的行数也全部计算进去，而我每次拉代码都用的 rebase ，怪不得我比不过别人啊，合着我写的代码全都算到别人的数据里面去了

从今天开始，继续突破自己底线，每次提交必选 merge ，反正 git 提交历史已经是一个粪坑了

[wolfan]

贵司领导可能觉得这样装逼吧，毕竟领导就爱 PUA 式管理。总得显得自己有能力驾驭尔等高级农民工的。

[Felldeadbird]

能够把代码行数来统计工作效率，说明公司想裁人，恶心人罢了。

根据之前类似贴子的回复，把那些包的代码 cv 复制一份。其次，循环全改手写。

[Yuanlaoer]

@nevin47 您想表达的重点是？

[Yuanlaoer]

@iyaozhen 那您觉得这个指标怎么样？

[ryan4290]

@chihiro2014 太二逼了哈哈哈

[solitude511]

哈哈哈哈
好奇今天改一个目录明天再改回来是不是也算

[Varobjs]

我一直习惯 git pull --rebase origin

原来 git merge 还有这 “优点”，涨姿势了

[BeautifulSoap]

@nothingistrue 我十分怀疑你有没有用过 Github

[Varobjs]

@shalk 然后有 bug 永远看最后一个提交是谁，不管改动的是啥，阁下如何应对

[nothingistrue]

@horizon #56 哦，原来是这个首先源分支上 「 rebase --no-ff 」，然后目标分支上 「 merge --ff-only 」，如果不能 rebase --no-ff 还不让做的 Github 专有的脑残方式。这个脑残方式是一定要禁止的，但请注意它并不是通常所说的 rebase merge 。

通常所说的 rebase merge ，是首先源分支上 「 rebase 」，然后目标分支上「 merge --no-ff 」，如果有冲突则可通过界面处理，这样的过程。Gitlab 、微软 Devops 、Gitea 等都支持这种方式，就 Github 出于提交签名的考虑，不支持这种方式。

[4771314]

@jasonyang9 手下的人未必都是精英，但是领导是真的智障

[BQsummer]

我们公司用 commit id 去重后算 commit 里的代码行数，你这种 rebase 的会算重，代码量大增，来我们公司吧 [狗头]

[iSecret]

你们是用的 Gitlab 吗？我司前段时间统计项目是从 Gitlab 拉取的 Merge 日志来统计影响行，然后有项目组是直接 Push 到 master 分支的，导致月均代码行数小于 1 行，笑死了。

[pkokp8]

奇数次提交 unix2dos
偶数次提交 dos2unix😁

[volCan0]

@IamLostInCoding 干着不累么

[KgM4gLtF0shViDH3]

@Dogtler 一个月不发工资就应该慌了，你怎么忍得住的

[iyaozhen]

@Yuanlaoer 我是 QA ，我不反对这个指标。怎么说呢，质量可视，总得需要一些指标

[chihiro2014]

@ryan4290 技术总监是日本回来的废物，跟国内起码脱节 10 年，笑死

[Yuanlaoer]

@iyaozhen 您这 2 条回复总结在一起，我帮你翻译成简单的普通话吧：“不认同但不想明说”

[nevin47]

@Yuanlaoer #63 千行缺陷密度在项目实操中很好用，用来评估项目质量是一个很合理的指标。类似你说的清空 ignore 这种操作，在 PR 的时候有 Maintainer 来拦截的，不会影响缺陷密度统计