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

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

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

11439 次点击
所在节点    程序员
91 条回复
deplivesb
2023-07-05 09:46:34 +08:00
问题来了,你的 bugfix 往里面合的时候通知了相关的人员了么?如果没有,活该被骂,要我我也骂你。
ljtfdt
2023-07-05 09:53:58 +08:00
要学会沟通,沟通完再提交不啥事就没有了么
accelerator1
2023-07-05 09:57:12 +08:00
出发点是好的,但是做法是不对的,跟有没有 protect 无关,有了 protect 你也要提交 mr 的,只不过你们现在的 mr 是口头通知。
bug 也分优先级、严重性,看你的描述,生成错误的文件名完全可以一行命令解决掉,但是这个错误要不要修复、什么时候修复可不是研发决定的。
raighne
2023-07-05 10:03:22 +08:00
真草台班子
iOCZ
2023-07-05 10:14:01 +08:00
@hokori 薪资是有个同事泡了会计,啥意思?
hokori
2023-07-05 10:20:08 +08:00
@iOCZ 所以知道这个总监的月薪 传出来了
yule111222
2023-07-05 10:22:29 +08:00
@wolfie 只有没有 CI ,CR 的团队才会遇到那么多 git 问题。连 protect 这种最基础的都没有,遇到任何问题都不稀罕
bk201
2023-07-05 10:43:23 +08:00
你这不按套路出牌啊,想怎么搞就怎么搞。protect 是强制措施,你自己的行为是自己应该约束自己的。就像法律不规定的话,你就可以违背道德乱搞了吗?
leeg810312
2023-07-05 10:57:40 +08:00
楼上好些个被点赞的回复,都是什么迷惑观点,居然还有人认为没有规定就是禁止,不要效率了是吧,什么都要请示又要被人说是个蜡烛,不点不亮咯。技术管理可以约束的非要放弃分支限制,用口头约定,既然放弃限制就是默认什么都可以提交,口头约定算个球,这个领导就是 nc 。
BruceTu
2023-07-05 11:00:28 +08:00
你的错更多一些
wintersun
2023-07-05 11:20:21 +08:00
A 、作为个体,反思自己:
1 、用户思维,为结果负责,很好的价值观
2 、团队协作,明文规则或口头约定,要坚守; 如果与最终价值准则冲突,要上下沟通,再决定是否特事特办

B 、作为团队领导,反思领导力:
1 、不当众批评个人,尤其是带情绪做人格判定乃至人身攻击。没有一个人喜欢被当众公开处刑。
2 、对事,也对人——
对事,是偶然发生还是频繁发生?前者特事特办,后者要反思自己定下的流程制度
对人,要先弄清楚动机。动机好,即便事情没办好,也不要指责。要有容错思维,鼓励和培养团队成员。再用正确的做事方法来处理,确保后续不会再犯。

C 、工程思维
效率、质量、成本,本身就是互相制约的三角。

成本受制的情况下,既要效率(合并都要由某人审核太麻烦),又要质量(一次“误”操作都没有),只能说要求很高,那就更需要提高每一个团队成员的能力并加强沟通协作,建立彼此间的信任。
cstj0505
2023-07-05 11:28:21 +08:00
用的公司 git ,主要版本没有 protect ,也是口头约定

这两周,有人直接在 develop 分支上修改,还有人自己提 pr 自己合,他自己觉得代码没问题但是实际上有问题
SACKJJKLL
2023-07-05 11:43:14 +08:00
敏捷开发,领导不在乎
JimmyChan1506
2023-07-05 11:43:39 +08:00
什么样的团队使用什么样的规定, 小团队没那么多限制非常正常, 个人经历, 100 人左右的团队, 也有过 30 人左右的团队, 从来没有对主分支做过任何权限限制做什么 protect, 也从来没出过代码方面的问题, 当然了, push force 之类的操作是肯定有限制的, 这个在 git server 上做就足够了 .

自己一声不吭在上线分支上提交了代码, 目测很可能也没有经过测试, 还是靠自己的 TL 细心才发现存在非必要代码, 人家批评你一点问题都没有, 你的做法只能证明你自己工程经验很差, 团队合作精神也不好.

当自己所在的团队存在自己觉得不合理的地方, 能提出来很好(同时也证明了, 你团队 TL 并不是不能讨论不同的做法), 但最终的结果与自己"认为正确"的做法不一致时, 要多了解对方做法的缘由, 他所顾虑的问题, 同时也需要妥协, 毕竟你自己的看法多半是基于自己过往的经验, 而这些经验是否正确不说, 肯定也不是每一个项目都合适. 这就叫做 Teamwork
henryhu
2023-07-05 11:46:20 +08:00
你的确错了。你认为这次私自 push 没问题,谁知道下次私自 push 会搞出什么幺蛾子
adoal
2023-07-05 12:07:28 +08:00
你看,你也觉得生产分支应该 protect……所以没 protect 了你就任意提交?你是坚持自己的底线,还是跟着外部条件摆烂?
YienX
2023-07-05 12:16:07 +08:00
只能说最后一句好像在骂你自己
xz410236056
2023-07-05 12:42:13 +08:00
@dqzcwxb #22 真觉得这事儿这么严重为啥能直接 push ?还不是又菜毛病又多
sikaco
2023-07-05 12:46:51 +08:00
看到大部分人都在骂你,我就放心了。
其他有些评论简直是搞笑,说那个领导不设 protect 是为了权利最大化方便整人,戏是不是太多了。。
iOCZ
2023-07-05 12:59:55 +08:00
团队应该严格按照分支工作流程来

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

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

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

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

© 2021 V2EX