这是一个创建于 365 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前发了个帖子吐槽公司统计代码行数 前情提要
经过我两个月的奋斗，各种水行数，甚至突破自己底线贴工具类到代码里面，发现怎么都比不过别人的代码行数，今天才发现，原来公司统计是会把 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
sqfphoenix OP @iOCZS 现在每个月做的最多的事情就是，扯皮，甩锅，算自己的数据，数据不好直接通报批评
|
 |
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
joyhub2140 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 364 天前 via iPhone
好奇挪动目录的改动也会统计进去吗😿
|
 |
37
chihiro2014 364 天前 1
我依稀记得我上一家国企，自从我离职之后，开始统计每人每天代码行数，要求不低于 3000 行每天。我想一个系统 4-5 人维护，一个月怕不是 os 都搞出来了。
实际：new 一个对象需要 new 七八次，最后赋值，用 set 全走一遍，以此达成目标。 笑死。 据内部人员表示，目前上海和合肥两地的开发基本裁完，笑死 |
 |
38
param 364 天前 via Android
两个空格转成四个空格提交一次，单引号转双引号提交一次。适用于 js 等语言。
|
 |
39
ZE3kr 364 天前 via iPhone
所有空格转换成换行，Tab 转换成 4 个换行，适合非 Python 等语言
|
 |
40
jasonyang9 364 天前 via Android
智障领导精英就是这样的局面
|
 |
41
wupher 364 天前
你应该做个工具，方便代码风格转换，有偿。
然后在同事间消然推广。 |
 |
42
hobbitlhy 364 天前 1
统计代码行数呀，哪个把 maven 去掉吧，这东西用不上了
|
 |
43
hazardous 364 天前
merge 提交行数，只是修改过的行数吗？感觉很合理啊。难道是整个文件的行数？
|
 |
44
jifengg 364 天前 2
完全不敢现象（可以想象）一年后你们领导看到统计出来的总行数 几十亿 时的表情。
|
 |
47
horizon 364 天前
你在主分支 rebase ？
|
 |
48
ccraohng 364 天前
break-width 改成 10
|
 |
49
shellcodecow 364 天前
我有个很好的经验 这次统计代码，我把 csv 10 万行的测试文件误提交到了 git ，结果我是代码量最高的人（没人审核） lol
|
 |
51
Goooooos 364 天前
把一个几千行的文件，全部索引改为两个空格，隔天又改回 4 个空格
那每天的修改行数不就上天了吗 |
 |
52
nothingistrue 364 天前
@BeautifulSoap #33 第一，Github PR 合并选项就没有 rebase 。第二，rebase 的方向是从其他分支变更到个人分支，控制权完全在个人手上，你最多只能禁止 rebase 之后的 force push ，但禁止不了 rebase 。所以你说得是那个 rebase 。
|
 |
53
shalk 364 天前 1
所有代码格式化一下，直接排名第一
|
 |
54
sooong 364 天前 1
今天你格式化下代码，明天别人格式化下，你们都有美好的未来！
|
 |
55
justfindu 364 天前
哈哈哈哈 可以选一个最多提交了 然后 merge 它
|
|
56
horizon 364 天前
|
 |
57
psklf 364 天前
换行改一下啊，linux 换行和 windows 换行
|
 |
59
IamLostInCoding 364 天前 via iPhone
@xianyv 我这也有，代码量，bug 率😂
|
 |
60
fredweili 364 天前
明年也许就不用了
|
 |
61
wolfan 364 天前
贵司领导可能觉得这样装逼吧，毕竟领导就爱 PUA 式管理。总得显得自己有能力驾驭尔等高级农民工的。
|
 |
62
Felldeadbird 364 天前
能够把代码行数来统计工作效率，说明公司想裁人，恶心人罢了。
根据之前类似贴子的回复，把那些包的代码 cv 复制一份。其次，循环全改手写。 |
 |
65
ryan4290 364 天前
@chihiro2014 太二逼了哈哈哈
|
 |
66
solitude511 364 天前
哈哈哈哈
好奇今天改一个目录明天再改回来是不是也算 |
 |
67
Varobjs 364 天前
我一直习惯 git pull --rebase origin
原来 git merge 还有这 “优点”，涨姿势了 |
|
68
BeautifulSoap 364 天前
@nothingistrue 我十分怀疑你有没有用过 Github
|
|
70
nothingistrue 364 天前
@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 364 天前
@jasonyang9 手下的人未必都是精英，但是领导是真的智障
|
 |
72
BQsummer 364 天前
我们公司用 commit id 去重后算 commit 里的代码行数，你这种 rebase 的会算重，代码量大增，来我们公司吧 [狗头]
|
 |
73
iSecret 364 天前
你们是用的 Gitlab 吗？我司前段时间统计项目是从 Gitlab 拉取的 Merge 日志来统计影响行，然后有项目组是直接 Push 到 master 分支的，导致月均代码行数小于 1 行，笑死了。
|
 |
74
pkokp8 364 天前
奇数次提交 unix2dos
偶数次提交 dos2unix😁 |
 |
75
volCan0 364 天前 via Android
@IamLostInCoding 干着不累么
|
 |
76
KgM4gLtF0shViDH3 364 天前
@Dogtler 一个月不发工资就应该慌了，你怎么忍得住的
|
|
78
chihiro2014 363 天前
@ryan4290 技术总监是日本回来的废物，跟国内起码脱节 10 年，笑死
|
 |
80
nevin47 359 天前
@Yuanlaoer #63 千行缺陷密度在项目实操中很好用，用来评估项目质量是一个很合理的指标。类似你说的清空 ignore 这种操作，在 PR 的时候有 Maintainer 来拦截的，不会影响缺陷密度统计
|
|
81
Yuanlaoer 359 天前
@nevin47 我说 gitignore 那个是开玩笑讲的。
像你讲的，“千行缺陷密度”，如果能把这三个名词定义清楚并在公司内达成共识，那这肯定是一个非常高质量的指标。 来吐槽的人，显然所处的团队的统计方式有很多不合理的地方，都不用说 `.git` 和 `.gitignore` 了，像是`node_module` 或是其他包管理可能都没做特殊处理，还可以用各种 lint 来操作。而行数统计就是直接粗暴叠加每个 commit 中的行数。 一句话总结：某人把一个连名字都没搞明白的理论直接搬到团队里，实际应用时一塌糊涂 |
 |
82
xinshoushanglu 359 天前
哈哈经典套路
|
Select Language