挺生气的,关于领导 git 管理的一顿臭骂

2023-07-04 22:43:44 +08:00
 breadykidliu

事情是这样的
目前项目发生产的分支没有做 protect ,任何人都能往上 push
(之前提议过生产分支要做 protect ,某领导以每次合并都要由某人审核太麻烦被拒)
组里定的规矩(不成文,口口相传,也不知道我掌握的是否全面)是:迭代发生产时,将功能代码合上生产分支
今天突然要发个 hotfix ,看 commit 记录发现了我提交的某个 bugfix
tl 直接质问我为什么当天不发版的内容要合上生产分支,
我说这个 bug 拖一天生产上每日生成的文件名就错一天,肯定越早上线修复越好
然后他开始 balabala 一顿说
我觉得你们自己不做限制,规定又不成文,就别怪其他人往上合,
单个无依赖的 commit 你实在不允许上线,你 drop 掉就行了,完事后和当事人说下,强调下规定,就可以了,
你冲我 balabala 叫个 p 啊,大煞笔!

11287 次点击
所在节点    程序员
91 条回复
LeegoYih
2023-07-04 22:50:28 +08:00
所有你为什么不先沟通再提交?你还觉得你自己对了?😅
wdlth
2023-07-04 22:52:48 +08:00
如果按照代码库管理的方式来看,你们 TL 的做法也没错,因为上线的主要是功能需求,如果不成功是可能进行整体回滚的,回滚的话你的这个 hotfix 也是留不下来的。
如果你只是改了很小的一部分的话,可以先用旧版本的代码拉分支,然后在当前版本的代码上验证,等新版本主要的功能需求都合并后,再通过捡樱桃方式合并过来。
Vegetable
2023-07-04 22:55:26 +08:00
protect 本质是避免误操作。没有 protect 并不意味着这个分支可以自由的 push ,这是两回事。

网上冲浪多说一句你别太介意,我觉得这个事儿你应该承认错误,领导水平如果不说,你这么提交代码很冒失,出了问题不是你一个人被问责
BeautifulSoap
2023-07-04 22:58:31 +08:00
虽然我自己管理的项目偶尔也会嫌麻烦直接 push ,但不是自己管理的项目不是自己负责任的话,直接往生产环境的分支上 push 前最好还是说一声
IvanLi127
2023-07-04 23:07:08 +08:00
你如果是误操作的话,那就是你的领导不听忠言,不开保护。。

可你不是误操作啊,那保护不保护和你意图无关呀


要我说,你这次提交只是脑袋一热,太上心项目了,要是开了保护,至少能避免这种意外。要不是这样的话,那这锅,你的领导分不到多少
foolishcrab
2023-07-04 23:14:03 +08:00
虽然你是有责任心且你们组确实管理混乱。
但是你不说一声往 release push 这个事,你要认识到严重性的。不管对你个人还是对项目而言都很严重
foolishcrab
2023-07-04 23:16:06 +08:00
不过确实保护分支都不开的项目,这领导没资格在这说分支规范的事
awolf
2023-07-04 23:39:07 +08:00
fire it
iintothewind
2023-07-05 04:12:50 +08:00
你们项目确实管理混乱,领导的问题,你不能改变最好的作法还是处事谨慎,自保为上吧,要不就换工作。
levelworm
2023-07-05 05:48:47 +08:00
的确管理混乱。。。这种事情吧,以后记得一定要留痕,要 cc 所有相关人,省的之后说不清楚。对方不回信就什么都不做。
klo424
2023-07-05 08:24:56 +08:00
无论是人工管理还是系统管理,你的做法都是越权的,错就错了,以后注意就是了。
AmosLi
2023-07-05 08:30:48 +08:00
首先,生产分支不做保护不合适,说什么怕麻烦的理由站不住!
其次,楼主修复 bug 确实应该给领导知会一声。你没有打招呼,私自提交不合适
litchinn
2023-07-05 08:41:12 +08:00
没有测试吗,不懂为啥会直接往生产分支上 push ,不应该先 push 到开发或测试分支上,生产分支从 dev/test 上拉吗,不清楚你们的流程,不过多评价
Frankcox
2023-07-05 08:49:06 +08:00
程序正义是工作中的重中之重,你可以觉得领导 SB ,领导也确实可能 SB 。但你应该做的是要么指出问题所在,提出解决方案;如果确实没法推动改变,那就拍拍屁股走人,坐等他们出事。而不是擅自按照自己的意愿去做。
theprimone
2023-07-05 08:53:37 +08:00
领导也看 V 站咋办?
zysuper
2023-07-05 08:56:45 +08:00
既然你都觉得领导煞笔了,那发这个帖子,是想找到同仁的认同感,还是想得到什么呢?
zed1018
2023-07-05 08:58:19 +08:00
确实,但凡是因为觉得麻烦就省掉流程,出事只是时间问题。
我们组都是所有仓库全 protected ,所有开发都自行 fork ,自己怎么玩都可以,但是要上测试环境就走 fork-based 的合并请求进主线,主线自动走 ci/cd 打包,gitops 自动发布测试。上生产另外走发布 tag 流程。虽然麻烦,但是有卡关的地方,认为事故概率会低很多。
zed1018
2023-07-05 08:58:39 +08:00
而且换句话讲,这么做上线的神圣感会强一点,不会太随意
dif
2023-07-05 09:06:47 +08:00
上线的分支一般都比较重要,不说允许不允许合并吧。至少要通知一声。
9113946
2023-07-05 09:07:27 +08:00
领导的角度没错,你的做法欠妥当

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/954122

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX