看到同事的 PR 里搞手动对齐，还进了 master，比吃口 shi 还难受

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 105 天前的主题，其中的信息可能已经有所发展或是发生改变。

加一个枚举变量，结果名字太长，重新对齐改了几十行，加我 review 的时候我给提了 comment ，要她缩短变量名，不要搞手动对齐，然后就没管了，毕竟我不是 commiter ，只有 approve 权限，没 merge 权限。

今天我要把她和几个人之前提交的变量合并到一个结构体里，结果看记录，瞬间被喂了一口 shi ，日麻整个枚举类型全都是她提交的记录，还得回退一个 MR 才能看到哪些是真正她提交的。

40 条回复 • 2024-08-16 10:52:25 +08:00

l4ever

105 天前

走一个就行了

MoYi123

105 天前

有 review 机制, CI 里没有 fmt 吗? 如果符合 fmt, 手动对齐又有什么影响?

wanmyj

105 天前

@MoYi123 我在说 git 提交记录被无意义的多刷一遍，跟 fmt 有什么关系？

maxwellz

105 天前

逆天...

cxsz

105 天前

可以统一配置下 git hooks 在 commit 前格式化代码，或者加到 ci 里面

bugmaker233

105 天前

没看懂你在说什么.....又不是不能用.jpg

kokutou

105 天前

还是工作量不够大
居然还有时间强迫症对齐

davin

105 天前

push 之前 husky + 各种 auto fix 走一遍先，书同文，车同轨。避免占用额外的开发时间

C4D4zRNpq9vFSlJW

105 天前

关键词：《她》

mcfog

105 天前

不是 ignore whitespace 吗

ajaxgoldfish

105 天前

没看懂，能举个例子吗 op ，属实纳闷

wanmyj

105 天前

@ajaxgoldfish 没看懂说明这个做法没太影响到你。

简单说，git 有个 blame 功能，能直观看到每行代码的上次修改人。她的行为导致了 git blame 的返回结果是每行代码的修改人都是她。

ajaxgoldfish

105 天前 via Android

@wanmyj 明白了。多谢。

2020583117

105 天前

@ajaxgoldfish 前期无所谓，你想想后期你先看看这个功能是谁写的，然后发现全是一个人写的，这不是玩呢吗？问谁都找不到人😁

zhtyytg

105 天前

@2020583117 倒也不是找不到，而是每次都要翻文件修改记录，很烦

sks4728

105 天前

不是不能用，用不了就走一个

ck65

105 天前

她喂你 shi ，你赏她饭（

nyxsonsleep

105 天前

idea 可以直接按行查看多次提交的历史

Donaldo

105 天前

@wanmyj #3 他意思应该是如果有 fmt 可能就不会出现需要手动对齐的问题了

MrSheng

105 天前

A 改动了代码 3-5 行，B 现在需要修改第 2 行，但是因为额外的对齐操做而动了 3-5 行。这导致 blame 的时候看到的 2-5 行都是 B 进行操作的，是这个意思吗？

Jinnrry

105 天前

@wanmyj #12 这都习惯了，下次遇到问题的时候你也装傻，直接找到她，xxx ，你看下这里啥问题呢，我看记录是你改的。

GrayXu

105 天前

@wanmyj #3 他说的没问题，就是你们 git 流程的问题，这种就给自动化做

crysislinux

105 天前 via Android

我们项目五六年了，现在有人力主引入 prettier 来格式化，后果就像你说的，git blame 废了一大半。。

Zenon

105 天前

@wanmyj #12 卧槽，看你描述我都开始生气了

hxndg

105 天前

@wanmyj 还是没懂，如果调用某个 bot 或者统一 format 不是一样得会退版本吗？这个不能直接 cherrypick 是吗？

AirCrusher

105 天前

你需要.git-blame-ignore-revs： https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa98b9e279175f2

andforce

105 天前 via iPhone

fmt 得在工程一开始就得有

1xiaozi

105 天前 via Android

@wanmyj 遇到过一样的同事。想请问下是怎么提交会导致这种情况。

jeesk

105 天前 via Android

@AirCrusher 改动过的才允许格式化会减少很多坑

cheetah

105 天前

@crysislinux 还是好处大于坏处的。而且还有 #26 说的 .git-blame-ignore-revs

crysislinux

105 天前

@cheetah 没早发现这个，不然让他们一次性格式化了。现在是改到哪个文件格式化哪个。

cheetah

105 天前

@crysislinux 这太难受了，赶紧格式化一次吧

yb2313

105 天前

所有地方他都动了, 那问题都找他解决

wanmyj

105 天前

@MrSheng yes ，引入的 git 记录非常不方便。
@hxndg "如果调用某个 bot 或者统一 format 不是一样得会退版本吗？" --- 其实 bot 的记录也是蛮讨厌，但最起码能看到修改人是 bot ，不至于分不清。和 cherrypick 关系不太大。
@1xiaozi “怎么提交会导致这种情况” --- 没太明白你想问什么

wanmyj

105 天前

@AirCrusher 确实是个神器，但我看了下，还不太能用，她是 formating 和 editing 放在一个 commit 提交上去了，这个 commit 如果 ignore 了又会导致正式修改的 blame 受影响。So~ fine...

1xiaozi

105 天前

@wanmyj 就是 [她的行为导致了 git blame 的返回结果是每行代码的修改人都是她。] 这个情况

1xiaozi

105 天前

@1xiaozi 补充一下、正常使用 add/commit ，merge ，rebase 都没出现过这个现象。但是第一次看到都震惊了、不知道怎么做到的

wanmyj

105 天前

@1xiaozi 这个情况和 git 命令没关系，单纯就是因为她修改了那些本不应该碰的代码，并提交了这些修改。

ffw5b7

104 天前 via Android

是习惯吧，我每次改完代码都会 ctrl s;ctrl l.保存加格式化。
话说代码不格式化不难受吗？
不是没有手动对齐吧。

jwj

104 天前

这都小儿科