这是一个创建于 543 天前的主题，其中的信息可能已经有所发展或是发生改变。
事情是这样的
目前项目发生产的分支没有做 protect ，任何人都能往上 push
（之前提议过生产分支要做 protect ，某领导以每次合并都要由某人审核太麻烦被拒）
组里定的规矩（不成文，口口相传，也不知道我掌握的是否全面）是：迭代发生产时，将功能代码合上生产分支
今天突然要发个 hotfix ，看 commit 记录发现了我提交的某个 bugfix
tl 直接质问我为什么当天不发版的内容要合上生产分支，
我说这个 bug 拖一天生产上每日生成的文件名就错一天，肯定越早上线修复越好
然后他开始 balabala 一顿说
我觉得你们自己不做限制，规定又不成文，就别怪其他人往上合，
单个无依赖的 commit 你实在不允许上线，你 drop 掉就行了，完事后和当事人说下，强调下规定，就可以了，
你冲我 balabala 叫个 p 啊，大煞笔！
 |
1
LeegoYih 2023-07-04 22:50:28 +08:00  42
所有你为什么不先沟通再提交？你还觉得你自己对了？😅
|
 |
2
wdlth 2023-07-04 22:52:48 +08:00
如果按照代码库管理的方式来看，你们 TL 的做法也没错，因为上线的主要是功能需求，如果不成功是可能进行整体回滚的，回滚的话你的这个 hotfix 也是留不下来的。
如果你只是改了很小的一部分的话，可以先用旧版本的代码拉分支，然后在当前版本的代码上验证，等新版本主要的功能需求都合并后，再通过捡樱桃方式合并过来。 |
 |
3
Vegetable 2023-07-04 22:55:26 +08:00 7
protect 本质是避免误操作。没有 protect 并不意味着这个分支可以自由的 push ，这是两回事。
网上冲浪多说一句你别太介意，我觉得这个事儿你应该承认错误，领导水平如果不说，你这么提交代码很冒失，出了问题不是你一个人被问责 |
 |
4
BeautifulSoap 2023-07-04 22:58:31 +08:00 via Android
虽然我自己管理的项目偶尔也会嫌麻烦直接 push ，但不是自己管理的项目不是自己负责任的话，直接往生产环境的分支上 push 前最好还是说一声
|
 |
5
IvanLi127 2023-07-04 23:07:08 +08:00 via Android 1
你如果是误操作的话，那就是你的领导不听忠言，不开保护。。
可你不是误操作啊，那保护不保护和你意图无关呀 要我说，你这次提交只是脑袋一热，太上心项目了，要是开了保护，至少能避免这种意外。要不是这样的话，那这锅，你的领导分不到多少 |
 |
6
foolishcrab 2023-07-04 23:14:03 +08:00 via iPhone 7
虽然你是有责任心且你们组确实管理混乱。
但是你不说一声往 release push 这个事，你要认识到严重性的。不管对你个人还是对项目而言都很严重 |
|
7
foolishcrab 2023-07-04 23:16:06 +08:00 via iPhone
不过确实保护分支都不开的项目，这领导没资格在这说分支规范的事
|
 |
8
awolf 2023-07-04 23:39:07 +08:00
fire it
|
 |
9
iintothewind 2023-07-05 04:12:50 +08:00
你们项目确实管理混乱，领导的问题，你不能改变最好的作法还是处事谨慎，自保为上吧，要不就换工作。
|
 |
10
levelworm 2023-07-05 05:48:47 +08:00
的确管理混乱。。。这种事情吧，以后记得一定要留痕，要 cc 所有相关人，省的之后说不清楚。对方不回信就什么都不做。
|
 |
11
klo424 2023-07-05 08:24:56 +08:00
无论是人工管理还是系统管理，你的做法都是越权的，错就错了，以后注意就是了。
|
 |
12
AmosLi 2023-07-05 08:30:48 +08:00
首先，生产分支不做保护不合适，说什么怕麻烦的理由站不住！
其次，楼主修复 bug 确实应该给领导知会一声。你没有打招呼，私自提交不合适 |
 |
13
litchinn 2023-07-05 08:41:12 +08:00
没有测试吗，不懂为啥会直接往生产分支上 push ，不应该先 push 到开发或测试分支上，生产分支从 dev/test 上拉吗，不清楚你们的流程，不过多评价
|
 |
14
Frankcox 2023-07-05 08:49:06 +08:00
程序正义是工作中的重中之重，你可以觉得领导 SB ，领导也确实可能 SB 。但你应该做的是要么指出问题所在，提出解决方案；如果确实没法推动改变，那就拍拍屁股走人，坐等他们出事。而不是擅自按照自己的意愿去做。
|
 |
15
theprimone 2023-07-05 08:53:37 +08:00
领导也看 V 站咋办？
|
 |
16
zysuper 2023-07-05 08:56:45 +08:00
既然你都觉得领导煞笔了，那发这个帖子，是想找到同仁的认同感，还是想得到什么呢？
|
 |
17
zed1018 2023-07-05 08:58:19 +08:00
确实，但凡是因为觉得麻烦就省掉流程，出事只是时间问题。
我们组都是所有仓库全 protected ，所有开发都自行 fork ，自己怎么玩都可以，但是要上测试环境就走 fork-based 的合并请求进主线，主线自动走 ci/cd 打包，gitops 自动发布测试。上生产另外走发布 tag 流程。虽然麻烦，但是有卡关的地方，认为事故概率会低很多。 |
|
18
zed1018 2023-07-05 08:58:39 +08:00
而且换句话讲，这么做上线的神圣感会强一点，不会太随意
|
 |
19
dif 2023-07-05 09:06:47 +08:00 1
上线的分支一般都比较重要，不说允许不允许合并吧。至少要通知一声。
|
 |
20
9113946 2023-07-05 09:07:27 +08:00
领导的角度没错，你的做法欠妥当
|
 |
21
yule111222 2023-07-05 09:10:11 +08:00 1
LS 几个人别装逼了，生产分支不 protect 能直接 push 显然是技术管理问题，别怪小弟
|
 |
22
dqzcwxb 2023-07-05 09:14:39 +08:00
做错了事还嘴硬
|
 |
23
hokori 2023-07-05 09:16:46 +08:00
我告诉你，我之前公司的一个总监，git 不会，linux 不懂，照样月入 5w+。 薪资是有个同事泡了会计，不过那个总监 5 个月就走了，应该是劝退的。
|
 |
24
sujin190 2023-07-05 09:17:44 +08:00 via Android
严格来说这样确实不对，口头约定也是规则，现在出来很多规则外也还有软规则，之所以这样选择完全是基于沟通协调协作成本考量，类比于现实法律这个规则并不会也不能事事俱到，我们也还要遵守很多道德伦理方面的规则，再说吧如果你处在一个事事都有硬规则，否则大家就钻空子的工作环境，你也会觉得很非常难受
比如这件事情中，发布分支不强制限制不可推送确实存在可以推送的可能，但是你在项目组提前说一说或者和 leader 提前说清楚再提交，和你直接不管不顾提交两者是完全不同的，想着更快修复问题是好事，好心要有好路径去完成事情才会有好结果，一般逻辑中人家把这个称为情商 |
 |
25
QlanQ 2023-07-05 09:18:10 +08:00
一般不都是 protected 然后走 merge 么
|
 |
26
ql562482472 2023-07-05 09:20:09 +08:00 1
我建议你立刻去和领导道歉，就说
“领导，我意识到这个做法是错误的了，即使没有 protect ，我也不应将没规划的内容提交到版本分支上。” 这样你的意图能够达到（加 protect ），在领导那边的印象分也能赚回来。 当然的建议是我比较功利了，但是我觉得对你真的有好处 |
 |
27
8355 2023-07-05 09:21:20 +08:00
你们没看懂，op 是在倒逼负责人开启生产分支 protect 用自己的方式保护生产分支👍
|
 |
28
kalman03 2023-07-05 09:22:29 +08:00 1
在高效的小团队里面，约束的效率没有约定高！
|
 |
29
lambdaq 2023-07-05 09:26:15 +08:00
LZ 还年轻吧。。。。这领导是对你好。。。。。。。。。
等你变职场老油条了，你也会不可救药的避免担责走死板流程的。。。 |
 |
30
wolfie 2023-07-05 09:27:51 +08:00 1
@yule111222
看不懂上下文少说两句，任何 git 问题都可以推脱给 release 没 protect 是吧。 |
 |
31
akring 2023-07-05 09:28:20 +08:00 9
「我觉得你们自己不做限制，规定又不成文，就别怪其他人往上合」
你看，其实你也知道这样不好，只不过是想把锅甩到没规定上罢了 |
 |
32
GOOD21 2023-07-05 09:28:54 +08:00 1
一般规范都是出了事故才订立起来的。只有经历过一次，才知道什么叫“敬畏上线”。
|
 |
33
polo3584 2023-07-05 09:30:48 +08:00
小团队确实直接 push 效率高，不过 push 截图到群通知其他人还是很有必要的吧。。。
|
 |
34
dcsite 2023-07-05 09:30:53 +08:00
你们 TL 确实是大煞笔…… 感觉完全是情绪化做事。
用邪恶一点的想法，生产分支不设限目的就是，可以权利最大化，随时可以整人…… |
 |
35
nothingistrue 2023-07-05 09:32:38 +08:00 1
日常管理的规则是「规无约定则禁止」，并不是「规无禁止即可行」。刚入职场的小年轻容易把二者搞翻而碰壁。
|
 |
36
tabris17 2023-07-05 09:33:59 +08:00
我觉得你工作心态有问题
“bug 拖一天生产上每日生成的文件名就错一天” 关自己什么事呢，管他呢 |
 |
37
zhio 2023-07-05 09:37:48 +08:00
你的 tl, 逛不逛 V2EX 啊、
|
 |
38
lingeo 2023-07-05 09:38:24 +08:00
git flow 不是靠那个 protect 来实现的，自己平时没有养成习惯，就当涨记性了吧。
你单独 commit 了 bugfix ，可以 revert 你的 bugfix 。 |
 |
39
MuscleOf2016 2023-07-05 09:44:29 +08:00
不是自己主要负责的项目，就不要直接往 master push 了。应该走提合并请求的流程。
|
 |
40
arnoldxiao 2023-07-05 09:44:48 +08:00
@tabris17 血的教训
|
 |
41
deplivesb 2023-07-05 09:46:34 +08:00 2
问题来了，你的 bugfix 往里面合的时候通知了相关的人员了么？如果没有，活该被骂，要我我也骂你。
|
 |
42
ljtfdt 2023-07-05 09:53:58 +08:00
要学会沟通，沟通完再提交不啥事就没有了么
|
 |
43
accelerator1 2023-07-05 09:57:12 +08:00
出发点是好的，但是做法是不对的，跟有没有 protect 无关，有了 protect 你也要提交 mr 的，只不过你们现在的 mr 是口头通知。
bug 也分优先级、严重性，看你的描述，生成错误的文件名完全可以一行命令解决掉，但是这个错误要不要修复、什么时候修复可不是研发决定的。 |
 |
44
raighne 2023-07-05 10:03:22 +08:00
真草台班子
|
|
47
yule111222 2023-07-05 10:22:29 +08:00
@wolfie 只有没有 CI ，CR 的团队才会遇到那么多 git 问题。连 protect 这种最基础的都没有，遇到任何问题都不稀罕
|
 |
48
bk201 2023-07-05 10:43:23 +08:00
你这不按套路出牌啊，想怎么搞就怎么搞。protect 是强制措施，你自己的行为是自己应该约束自己的。就像法律不规定的话，你就可以违背道德乱搞了吗？
|
 |
49
leeg810312 2023-07-05 10:57:40 +08:00
楼上好些个被点赞的回复，都是什么迷惑观点，居然还有人认为没有规定就是禁止，不要效率了是吧，什么都要请示又要被人说是个蜡烛，不点不亮咯。技术管理可以约束的非要放弃分支限制，用口头约定，既然放弃限制就是默认什么都可以提交，口头约定算个球，这个领导就是 nc 。
|
 |
50
BruceTu 2023-07-05 11:00:28 +08:00
你的错更多一些
|
 |
51
wintersun 2023-07-05 11:20:21 +08:00 2
A 、作为个体，反思自己：
1 、用户思维，为结果负责，很好的价值观 2 、团队协作，明文规则或口头约定，要坚守； 如果与最终价值准则冲突，要上下沟通，再决定是否特事特办 B 、作为团队领导，反思领导力： 1 、不当众批评个人，尤其是带情绪做人格判定乃至人身攻击。没有一个人喜欢被当众公开处刑。 2 、对事，也对人—— 对事，是偶然发生还是频繁发生？前者特事特办，后者要反思自己定下的流程制度 对人，要先弄清楚动机。动机好，即便事情没办好，也不要指责。要有容错思维，鼓励和培养团队成员。再用正确的做事方法来处理，确保后续不会再犯。 C 、工程思维 效率、质量、成本，本身就是互相制约的三角。 成本受制的情况下，既要效率（合并都要由某人审核太麻烦），又要质量（一次“误”操作都没有），只能说要求很高，那就更需要提高每一个团队成员的能力并加强沟通协作，建立彼此间的信任。 |
 |
52
cstj0505 2023-07-05 11:28:21 +08:00
用的公司 git ，主要版本没有 protect ，也是口头约定
这两周，有人直接在 develop 分支上修改，还有人自己提 pr 自己合，他自己觉得代码没问题但是实际上有问题 |
 |
53
SACKJJKLL 2023-07-05 11:43:14 +08:00
敏捷开发,领导不在乎
|
 |
54
JimmyChan1506 2023-07-05 11:43:39 +08:00
什么样的团队使用什么样的规定, 小团队没那么多限制非常正常, 个人经历, 100 人左右的团队, 也有过 30 人左右的团队, 从来没有对主分支做过任何权限限制做什么 protect, 也从来没出过代码方面的问题, 当然了, push force 之类的操作是肯定有限制的, 这个在 git server 上做就足够了 .
自己一声不吭在上线分支上提交了代码, 目测很可能也没有经过测试, 还是靠自己的 TL 细心才发现存在非必要代码, 人家批评你一点问题都没有, 你的做法只能证明你自己工程经验很差, 团队合作精神也不好. 当自己所在的团队存在自己觉得不合理的地方, 能提出来很好(同时也证明了, 你团队 TL 并不是不能讨论不同的做法), 但最终的结果与自己"认为正确"的做法不一致时, 要多了解对方做法的缘由, 他所顾虑的问题, 同时也需要妥协, 毕竟你自己的看法多半是基于自己过往的经验, 而这些经验是否正确不说, 肯定也不是每一个项目都合适. 这就叫做 Teamwork |
 |
55
henryhu 2023-07-05 11:46:20 +08:00
你的确错了。你认为这次私自 push 没问题，谁知道下次私自 push 会搞出什么幺蛾子
|
 |
56
adoal 2023-07-05 12:07:28 +08:00 1
你看，你也觉得生产分支应该 protect……所以没 protect 了你就任意提交？你是坚持自己的底线，还是跟着外部条件摆烂？
|
 |
57
YienX 2023-07-05 12:16:07 +08:00
只能说最后一句好像在骂你自己
|
 |
58
xz410236056 2023-07-05 12:42:13 +08:00
@dqzcwxb #22 真觉得这事儿这么严重为啥能直接 push ？还不是又菜毛病又多
|
 |
59
sikaco 2023-07-05 12:46:51 +08:00
看到大部分人都在骂你，我就放心了。
其他有些评论简直是搞笑，说那个领导不设 protect 是为了权利最大化方便整人，戏是不是太多了。。 |
 |
60
iOCZ 2023-07-05 12:59:55 +08:00
团队应该严格按照分支工作流程来
|
 |
61
TestFlight 2023-07-05 13:27:16 +08:00 via iPhone
常在河边走，哪有不湿鞋。某一次 push 之后导致线上异常，造成资损进行复盘的时候，你就知道了，你是主要责任人，TL 是次要责任人
|
 |
62
Felldeadbird 2023-07-05 13:31:13 +08:00
为了楼主好，以后 push 前通知对应的人。
楼主估计工作被骂的少。 |
 |
63
xFrye 2023-07-05 13:35:05 +08:00
「挺生气的，关于下属不事先沟通私下合并代码的这件事」
|
 |
64
Belmode 2023-07-05 13:46:51 +08:00
这也不完全是你的错，工作上，遇事最好还是多沟通为好，千万不能相当然，不然会吃大亏的。需要做什么事，最好以邮件、会议、聊天群 at 所有人等方式，知会相关人员留痕。
不要听一些二极管的发言。 |
 |
65
jiangzm 2023-07-05 13:59:29 +08:00
同样作为 TL ， 我一直在组内强调的是 发布上线的代码需要经过 CR （可以组员之间），任何变更内容都要通过测试验证。上面看似是要求其实也是责任分摊，出了问题不会一个人担着
|
 |
66
kumiko 2023-07-05 14:08:14 +08:00
笑死，看来楼主没背过锅。多背几次有不会这么幼稚了
|
 |
67
shaozelin030405 2023-07-05 14:17:36 +08:00
别。。。别乱往生产分支合东西，只合说好的东西
|
 |
68
lincanbin 2023-07-05 14:17:58 +08:00
各打五十大板，你领导有管理责任，没有用权限管控等手段来限制这种事情的发生。
你的话则是代码合并上线没有及时周知。 |
 |
69
janus77 2023-07-05 14:21:49 +08:00
首先领导是不会改的，该改的最终还得是你
其次你的理由在我看来很可笑，早一点修复是更好，但是有谁规定一定要早一点修复了吗？相反，还真有人规定过不能随便合分支。另外晚一点上线又怎么样了呢？是会被骂还是会扣钱吗？ 很现实的问题。op 就是没搞清技术和管理的分界。 |
|
71
kalman03 2023-07-05 14:31:35 +08:00
@Desiree 就看怎么理解“约定”与“约束”，在一个高素质的开发团队，每个人都是自驱的，约定总是能运行的很好。就好比，有些公司对打卡没有要求，但实际上每个人都能自行约束自己，产出远远高于打卡的公司。
|
|
73
kalman03 2023-07-05 14:49:23 +08:00
@Desiree 那么是跟 OP 谈谈上班摸鱼的事情，还是开启强制打卡模式呢？我觉得这个其实是一个道理，ok ，温习下敏捷宣言
https://www.leangoo.com/wp-content/uploads/2018/07/leangoo%E6%95%8F%E6%8D%B7%E5%AE%A3%E8%A8%80.jpg |
 |
74
fresco 2023-07-05 15:05:51 +08:00
你想想为啥别人都没这个问题？
|
 |
75
xu45525584 2023-07-05 15:44:48 +08:00
事情怎么样先不说，不过你这性格在职场不好混的，混社会还是讲人情的
领导处不好，基本可以走人了，因为后面有好事也没你的份 |
 |
76
houzhiqiang 2023-07-05 16:11:40 +08:00
没有 code review 吗？不创建 pr 或者叫 mr 吗？
|
 |
77
chonphile1 2023-07-05 16:28:43 +08:00
乱麻一团，赶紧离职吧，从头到尾都是错。
1.代码提交都没有合理的分支规划 2.任何人都可以随意 push ？ 3.无测试、不审核的？ 4.你们这是能有多自信？ |
 |
78
lidashuang 2023-07-05 17:26:29 +08:00
多沟通
|
 |
79
realpg 2023-07-05 18:04:12 +08:00
OP 的问题
无论沟通还是做事都有问题 全面问题 |
 |
80
sampeng 2023-07-05 18:11:57 +08:00
没过测试，也没和任何人，包括 leader 说代码合并到 master 的。被喷没任何问题。
|
 |
82
xylxAdai 2023-07-05 20:08:55 +08:00
我们组有各种 git 提交的校验，但是你还是能直接 push --force 往上面硬塞，我怎么没见到有人塞呢？做错了就认错，觉得领导傻逼就说领导傻逼，不能自己先做错了被叼了，还觉得领导屌你这件事傻逼，总得讲点道理吧？
|
 |
83
AhECbt 2023-07-05 20:14:30 +08:00
没出问题最多挨顿屌，出了生产事故，拎包走人的除了你还得连带一票人。年轻人呐，虚心点吧。
|
 |
84
liaojl 2023-07-05 20:15:40 +08:00 via iPhone
网上发帖：你冲我 balabala 叫个 p 啊，大煞笔！
现实中：好的，老板。 |
 |
85
kamalei 2023-07-05 23:34:31 +08:00
中国的领导：出了问题都是人的原因
正常 manager：出了问题 应该反思流程 |
 |
86
tin3w5 2023-07-06 05:09:23 +08:00
楼主的这种情况我之前也遇到过，只不过当事人是一个开发团队的小迷糊，我是那个给他“擦屁股”的运维。
那个开发团队的 manager 对业务完全不熟，他早些年是写 VB 的，有点 C#的基础。但是现有的业务代码完全看不懂，遇到屁大点事就要把所有能拉到的人都拉过去帮他。小迷糊当天说什么都要把新 feature 发出去，但是当天出了点重大故障，小迷糊的 manager 正在被“一群外援”“簇拥着”，小迷糊就问了一句，他的新 feature 已经好了，我一会把这个 bug 修好之后就 push 了啊！然后让 manager 给他 merge PR 。 Manager 并不知道这个新 feature 和着急修的 bug ，屁关系没有。 然后你懂的，测试人员的测试代码只验证功能有没有问题，不验证生产环境的复杂数据进去之后处理的结果，然后 code 通过了检查，直接发给客户了。 后来，那天晚上，我们一群人为了小迷糊的莽撞提交而加班。最关键的是，小迷糊的 git commit 的 message 内容是“修复了 xxxx （那个 bug ）” 流程得完善，这没问题，但是人也得善于沟通啊！不然只会拔苗助长。 |
 |
87
imycc 2023-07-06 07:12:37 +08:00
首先你们的变更管理确实不规范，这个责任在项目负责人身上。但上线夹带私货，没出故障只是挨顿骂，出了生产事故轻则扣绩效，重则卷铺盖走人，你可长点心吧。
别说大型项目，我连两个人开发的小项目，都要走 MR 。一方面是方便做 CR ，另一方面出了问题也方便 revert 。正经项目的要求更加严格。你们那个拒绝设置保护分支的领导，路子太野了，可能还没被生产事故毒打过。 |
 |
88
cirzear 2023-07-06 10:08:26 +08:00
我宁愿什么都不做，也不愿做错。
|
 |
89
Redbeanw 2023-07-06 12:44:21 +08:00
不好评价，都做得不对。
|
 |
90
MrSheng 2023-07-06 17:03:26 +08:00
要不是你的 TL 负责发现你的 commit ，你现在可能在这里骂公司因为你修正了一个线上 bug 给你处分的事了。这不就是大傻逼公司？
|
 |
91
zhangyq008 2023-07-06 19:58:13 +08:00
你们路子太野了，没有任何发布规范
|
Select Language