这是一个创建于 653 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前发了个帖子吐槽公司统计代码行数 前情提要
经过我两个月的奋斗，各种水行数，甚至突破自己底线贴工具类到代码里面，发现怎么都比不过别人的代码行数，今天才发现，原来公司统计是会把 merge 提交的行数也全部计算进去，而我每次拉代码都用的 rebase ，怪不得我比不过别人啊，合着我写的代码全都算到别人的数据里面去了
从今天开始，继续突破自己底线，每次提交必选 merge ，反正 git 提交历史已经是一个粪坑了
 | 1 stinkytofu 2023-12-28 15:27:42 +08:00  7 这就是外行管内行， 结果一团糟。 |
 | 2 sadfQED2 2023-12-28 15:30:09 +08:00 via Android 哈哈哈，忍不住笑了。 |
 | 3 Yuanlaoer 2023-12-28 15:31:46 +08:00 一摸一样的情况在我们公司也有。 git 打开历史就是无数道彩虹 |
 | 4 xianyv 2023-12-28 15:32:19 +08:00 我靠,我以为没有统计代码行数的公司,没想到在 op 这里见到了 |
 | 5 iOCZS 2023-12-28 15:35:10 +08:00 应该管理需求和 commit 质量，而不是代码函数。一将无能,累死千军。 |
 | 6 qppq54s 2023-12-28 15:37:02 +08:00 1 哈哈我们公司是比加班时长  |
 | 7 |
 | 8 shyangs 2023-12-28 15:38:38 +08:00 14 什你停止使用 Git rebase 命令. (Link) |
 | 9 qinjiang 2023-12-28 15:39:58 +08:00 逆天，下次你把依赖库也提交了吧 |
| 10 sqfphoenix OP @qinjiang 已经在计划重新实现 jdk 了 |
 | 11 tediorelee 2023-12-28 15:42:28 +08:00 这种班上着不累吗 |
| 12 Yuanlaoer 2023-12-28 15:49:52 +08:00 在这里给大家讲个笑话吧 我们 CTO 的新政策：统计每千行的 bug 数 |
| 13 sqfphoenix OP @Yuanlaoer 我怀疑你和我一个公司，坐标杭州吗 |
 | 14 brom111 2023-12-28 15:55:09 +08:00 你这领导不会是新来的领导吧。我们之前有个领导就让我写了个代码统计的工具。但是会把 merge 的行数去掉。 后来他走了（真好 |
| 15 sqfphoenix OP @brom111 确实是今年的新领导，新官上任三把火 |
 | 16 nxforce 2023-12-28 15:58:17 +08:00 2 flutter 程序员内心独白： 居然有这等好事？ |
| 17 Yuanlaoer 2023-12-28 15:58:27 +08:00 2 @sqfphoenix 不是，我们公司也没有杭州办公室。 眼下这种大环境下，这种事儿不会少的。在特殊时期，亩产万斤的不光你们村，也不光我们村，是几乎每个村。 |
| 18 Yuanlaoer 2023-12-28 15:59:25 +08:00 @joyhub2140 哈哈哈哈，这就把 gitingore 清空 |
 | 19 via 2023-12-28 16:02:38 +08:00 2 why-you-should-stop-using-git-rebase[] |
 | 20 twofox 2023-12-28 16:09:19 +08:00 哈哈哈哈哈哈哈哈哈，谢谢你，笑出声了 |
 | 21 brader 2023-12-28 16:11:10 +08:00 还没体验过统计代码行数的公司。 先在你这里学点统计逻辑 0 0 ！ |
 | 22 mayday1997 2023-12-28 16:13:50 +08:00 公司发个预告函，想个办法去印象空间偷他心吧 |
| 23 sqfphoenix OP @mayday1997 我希望我是明智吾郎 |
 | 25 me221 2023-12-28 16:26:41 +08:00 1 你把 node_modules 提交了吧 |
 | 26 ShrinkLynn 2023-12-28 17:29:28 +08:00 1 node_modules 提交下随随便便几十万行（前司有人就这么干 |
 | 27 hauibojek 2023-12-28 17:34:10 +08:00 话说部门领导不懂技术么。 |
 | 28 bk201 2023-12-28 17:34:35 +08:00 我觉得管理层一个就好了，千万不能多。 |
 | 29 echoZero 2023-12-28 17:36:43 +08:00 我司就是 代码行数 处理 bug 数 |
 | 30 mdn 2023-12-28 17:38:00 +08:00 不用 rabase 看得脑壳痛，都不知道会不会在里面藏 bug |
 | 32 lxxxv5 2023-12-28 18:07:57 +08:00 via iPhone 美团 |
 | 33 BeautifulSoap 2023-12-28 18:33:06 +08:00 via Android rebase 尤其是 rebase quash 经常动不动引发冲突，甚至还经常导致 github 在 PR 里无法显示正确的 file changed 。所以我管的项目直接在 github 的 repo 设置里禁止 rebase 和 rebase squash 分支你看得乱就乱吧，反正只要保证几个重要不然分支不乱就行，剩下随便你们来。总比动不动 PR 合并出问题舒心 |
 | 34 Dogtler 2023-12-28 18:43:58 +08:00 上周我们老大也让我们统计代码行数了，想问下一般是在什么背景下才会做这种操作？ 我们老大是产品出身本身不会写代码，然后公司好几个月没发工资，先入为主一下，是不是公司要凉了呀。 |
| 35 sqfphoenix OP @Dogtler 各种情况都有，有些是外行装最懂的指挥内行，有些是公司不行了，但是你这个我建议你赶紧找工作止损。。。 |
 | 36 tonytonychopper 2023-12-28 22:20:31 +08:00 via iPhone 好奇挪动目录的改动也会统计进去吗 |
 | 37 chihiro2014 2023-12-28 22:37:29 +08:00 1 我依稀记得我上一家国企，自从我离职之后，开始统计每人每天代码行数，要求不低于 3000 行每天。我想一个系统 4-5 人维护，一个月怕不是 os 都搞出来了。 实际：new 一个对象需要 new 七八次，最后赋值，用 set 全走一遍，以此达成目标。 笑死。 据内部人员表示，目前上海和合肥两地的开发基本裁完，笑死 |
 | 38 param 2023-12-28 23:46:36 +08:00 via Android 两个空格转成四个空格提交一次，单引号转双引号提交一次。适用于 js 等语言。 |
 | 39 ZE3kr 2023-12-29 06:10:08 +08:00 via iPhone 所有空格转换成换行，Tab 转换成 4 个换行，适合非 Python 等语言 |
 | 40 jasonyang9 2023-12-29 08:08:35 +08:00 via Android 智障领导精英就是这样的局面 |
 | 41 wupher 2023-12-29 08:31:15 +08:00 你应该做个工具，方便代码风格转换，有偿。 然后在同事间消然推广。 |
 | 42 hobbitlhy 2023-12-29 08:50:48 +08:00 1 统计代码行数呀，哪个把 maven 去掉吧，这东西用不上了 |
 | 43 hazardous 2023-12-29 08:59:19 +08:00 merge 提交行数，只是修改过的行数吗？感觉很合理啊。难道是整个文件的行数？ |
 | 44 jifengg 2023-12-29 09:22:27 +08:00 2 完全不敢现象（可以想象）一年后你们领导看到统计出来的总行数 几十亿 时的表情。 |
 | 47 horizon 2023-12-29 09:30:57 +08:00 你在主分支 rebase ？ |
 | 48 ccraohng 2023-12-29 09:32:11 +08:00 break-width 改成 10 |
 | 49 shellcodecow 2023-12-29 09:35:26 +08:00 我有个很好的经验 这次统计代码，我把 csv 10 万行的测试文件误提交到了 git ，结果我是代码量最高的人（没人审核） lol |
 | 51 Goooooos 2023-12-29 09:36:35 +08:00 把一个几千行的文件，全部索引改为两个空格，隔天又改回 4 个空格 那每天的修改行数不就上天了吗 |
 | 52 nothingistrue 2023-12-29 09:43:25 +08:00 @BeautifulSoap #33 第一，Github PR 合并选项就没有 rebase 。第二，rebase 的方向是从其他分支变更到个人分支，控制权完全在个人手上，你最多只能禁止 rebase 之后的 force push ，但禁止不了 rebase 。所以你说得是那个 rebase 。 |
 | 53 shalk 2023-12-29 09:45:55 +08:00 1 所有代码格式化一下，直接排名第一 |
 | 54 sooong 2023-12-29 10:22:10 +08:00 1 今天你格式化下代码，明天别人格式化下，你们都有美好的未来！ |
 | 55 justfindu 2023-12-29 10:26:29 +08:00 哈哈哈哈 可以选一个最多提交了 然后 merge 它 |
| 56 horizon 2023-12-29 12:00:27 +08:00 |
 | 57 psklf 2023-12-29 13:04:55 +08:00 换行改一下啊，linux 换行和 windows 换行 |
 | 58 iyaozhen 2023-12-29 13:09:54 +08:00 |
 | 59 IamLosInCoding 2023-12-29 13:27:38 +08:00 via iPhone @xianyv 我这也有，代码量，bug 率 |
 | 60 fredweili 2023-12-29 13:30:14 +08:00 明年也许就不用了 |
 | 61 wolfan 2023-12-29 13:42:54 +08:00 贵司领导可能觉得这样装逼吧，毕竟领导就爱 PUA 式管理。总得显得自己有能力驾驭尔等高级农民工的。 |
 | 62 Felldeadbird 2023-12-29 13:47:34 +08:00 能够把代码行数来统计工作效率，说明公司想裁人，恶心人罢了。 根据之前类似贴子的回复，把那些包的代码 cv 复制一份。其次，循环全改手写。 |
 | 65 ryan4290 2023-12-29 13:57:18 +08:00 @chihiro2014 太二逼了哈哈哈 |
 | 66 solitude511 2023-12-29 14:15:01 +08:00 哈哈哈哈 好奇今天改一个目录明天再改回来是不是也算 |
 | 67 Varobjs 2023-12-29 14:20:24 +08:00 我一直习惯 git pull --rebase origin 原来 git merge 还有这 “优点”，涨姿势了 |
| 68 BeautifulSoap 2023-12-29 14:21:26 +08:00 @nothingistrue 我十分怀疑你有没有用过 Github |
| 70 nothingistrue 2023-12-29 14:25:23 +08:00 @horizon #56 哦，原来是这个首先源分支上 「 rebase --no-ff 」，然后目标分支上 「 merge --ff-only 」，如果不能 rebase --no-ff 还不让做的 Github 专有的脑残方式。这个脑残方式是一定要禁止的，但请注意它并不是通常所说的 rebase merge 。 通常所说的 rebase merge ，是首先源分支上 「 rebase 」，然后目标分支上「 merge --no-ff 」，如果有冲突则可通过界面处理，这样的过程。Gitlab 、微软 Devops 、Gitea 等都支持这种方式，就 Github 出于提交签名的考虑，不支持这种方式。 |
 | 71 4771314 2023-12-29 14:33:54 +08:00 @jasonyang9 手下的人未必都是精英，但是领导是真的智障 |
 | 72 BQsummer 2023-12-29 14:51:35 +08:00 我们公司用 commit id 去重后算 commit 里的代码行数，你这种 rebase 的会算重，代码量大增，来我们公司吧 [狗头] |
 | 73 iSecret 2023-12-29 15:04:16 +08:00 你们是用的 Gitlab 吗？我司前段时间统计项目是从 Gitlab 拉取的 Merge 日志来统计影响行，然后有项目组是直接 Push 到 master 分支的，导致月均代码行数小于 1 行，笑死了。 |
 | 74 pkokp8 2023-12-29 15:09:59 +08:00 奇数次提交 unix2dos 偶数次提交 dos2unix |
 | 75 volCan0 2023-12-29 15:22:29 +08:00 via Android @IamLostInCoding 干着不累么 |
 | 76 KgM4gLtF0shViDH3 2023-12-29 15:32:59 +08:00 @Dogtler 一个月不发工资就应该慌了，你怎么忍得住的 |
| 78 chihiro2014 2023-12-29 22:41:05 +08:00 @ryan4290 技术总监是日本回来的废物，跟国内起码脱节 10 年，笑死 |
 | 80 nevin47 2024-01-03 10:44:11 +08:00 @Yuanlaoer #63 千行缺陷密度在项目实操中很好用，用来评估项目质量是一个很合理的指标。类似你说的清空 ignore 这种操作，在 PR 的时候有 Maintainer 来拦截的，不会影响缺陷密度统计 |
| 81 Yuanlaoer 2024-01-03 14:42:53 +08:00 @nevin47 我说 gitignore 那个是开玩笑讲的。 像你讲的，“千行缺陷密度”，如果能把这三个名词定义清楚并在公司内达成共识，那这肯定是一个非常高质量的指标。 来吐槽的人，显然所处的团队的统计方式有很多不合理的地方，都不用说 `.git` 和 `.gitignore` 了，像是`node_module` 或是其他包管理可能都没做特殊处理，还可以用各种 lint 来操作。而行数统计就是直接粗暴叠加每个 commit 中的行数。 一句话总结：某人把一个连名字都没搞明白的理论直接搬到团队里，实际应用时一塌糊涂 |
 | 82 xinshoushanglu 2024-01-03 15:58:36 +08:00 哈哈经典套路 |
Select Language