如题，非常不解。难道大厂没有版本管理么？咨询了一下，说是一个人七八个项目，根本没有时间管理。 压力这么大的么？
This topic created in 330 days ago, the information mentioned may be changed or developed.
190 replies • 2025-12-19 14:53:19 +08:00
 |
urlkDec 12, 2025
101
不会的自己去学 https://learngitbranching.js.org/?locale=zh_CN
cherry pick 是很基础的命令, rebase 也是基于 cherry pick 的 |
 |
nealHuangDec 12, 2025
102
cherry pick 爽爆了，不过就是不好对比是否合并过
|
 |
jzhmDec 12, 2025
104
@Lemonadeccc #65 我用 rebase 多，但是我同事们用 merge 多
|
 |
cikiDec 12, 2025
105
cherry pick 是真不知道，大多数时候根本用不上
|
 |
chimissionDec 12, 2025
106
说明他没什么技术追求， 单纯够用就行。。。。
|
 |
shm7Dec 12, 2025
108
1 不用特别秀优越。
2 很多大厂用 gitlab 有刻板的分支流程，cherry pick 用的很少，都是从 main/master/dev 拉代码到 feature 分支，再合并回去，方便分支管理，和很多人共同开发时的秩序。 3 细碎工作很多+时间很忙的地方，才喜欢这里随便一个 hash 拉个分支出来，要是有 10 个人以上，分支 5 个以上，这种沟通维护成本显而易见的提升。 |
 |
109
看这个帖子浪费了宝贵的 5 分钟
|
1 |
shm7Dec 12, 2025
110
不信的可以在这里搜下 https://git-scm.com/book/zh/v2 你们自认为很牛的 cherrypick 技术，被放在哪些旮旯里
|
 |
Cu635Dec 12, 2025
112
看个人表现吧，是说非常不屑的那种“不知道”，还是一脸懵的那种“不知道”，还是说有点意外、有点小“震惊”（或者类似情绪）的不知道。
大厂因为老员工比例高一点，作为组长也好作为上司也好，如果是它们拒绝新事物，不使用版本管理工具，或者只是作为摆设，或者其它类似情况的话，加上底下员工工作压力这么大，员工确实有可能被挤压的没精力去了解一些基础知识。 @aiwoshishen #4 不一定，大厂本部也不一定好哪里去 |
 |
holy_sinDec 12, 2025
113
大厂重视的是道 你这都是术 哈哈
|
 |
bluehttDec 12, 2025
114
@mxT52CRuqR6o5 #22 帖子说的是 git add ，你说的是 git commit 。不过使用 idea 的时候，默认情况下，流程里已经很少看到 add 这步了，我修改文件后，按 esc 退出默认就是 add 。我喜欢使用 git 命令行，操作最多的也是 cherry pick 、rebase 、git flow 这种，很少会需要手动 git add 。
楼主用的可能是一些编辑器，vscode 、trae 之类的，修改之后还需要使用者手动 add 一下。个人使用的时候没有这个 git add 的需求。 |
 |
zhengfan2016Dec 12, 2025
115
@liuliuliuliu 可能是真的，我上家公司的大厂老程序员，基本都是 30-40 ，它们用 git 基本不 review 哪些和本次提交无关的，直接全部提交的，可能这就是高级程序员的从容吧
 |
 |
lynanDec 12, 2025
116
我喜欢用 GitHub Desktop ，简单流畅
|
 |
elronDec 12, 2025
117
@shm7 #111 你的意思是如果我在 develop 分支修了一个涉及较多文件的 bug ，线上版本还需要手动逐个复制修改？捞不捞啊，cherry-pick 神技被你贬低的一文不值，你要去银行开发，一个仓库几百个分支让你一个一个手动复制去吧
|
 |
DesdemorDec 12, 2025
118
cherry pick 好用爱用，但是不能说明一个人的水平高低，顶多是横向涉猎不多
|
 |
LXchienneDec 12, 2025
119
这非常符合程序员刻板印象，关注工具和技术，离业务太远，挣钱才是王道
|
 |
whoosyDec 12, 2025
120
@shm7 #110 一个仓库只有主线分支无所谓，想怎么弄怎么弄，就怕那种几十个分支对应几十个客户的项目，修一个共性问题，不可能每个分支都手动复制粘贴，cherry-pick 就是干这个事的
|
 |
paceewang1Dec 12, 2025
121
git 不知道怎么读？那 github 你总知道吧，`gay`hub
 |
 |
unco020511Dec 12, 2025
122
不可能工作这么多年不知道 cherry-pick 的吧,我感觉只要是项目复杂一点,就经常会用到 cherry-pick.其实 gui 和 cli 差别没那么大的,我更习惯用 gui.但是说在大厂不知道 add 和 cherry-pick,那就确实是够离谱的
|
 |
joinmouseDec 12, 2025
123
可能不用命令行操作，能快速熟悉就好了
|
 |
dongdongdongDec 12, 2025
124
经常用 cherry-pick ，有些东西不发版，有些东西发版，可以挑出来，非常好用
|
 |
liuliuliuliuDec 12, 2025
125
@zhengfan2016 从~从~容~容~游~刃~有~余~后面忘了...
|
 |
xz410236056Dec 12, 2025
126
@iloveyou 哪个 GUI 客户端没遴选这玩意。
|
 |
windmilllDec 12, 2025
127
40 岁不知道这些倒显得合理了，如果是 20 多岁的年轻程序员我觉得不正常
|
 |
mxT52CRuqR6o5Dec 12, 2025
128
@bluehtt #114 add 不就是为了选择性地 commit 文件吗？
|
 |
jaxjaxjaxDec 12, 2025
129
cherry-pick 这个我印象很深，翻译成中文就是“摘樱桃”，每个 commit 都是一个樱桃，git cherry-pick commit-id 就是摘取对应 commit-id 的樱桃哈哈
|
 |
SWALLOWWDec 12, 2025
131
不是，到底有没有人介绍下 cherry-pick 是干啥的
|
 |
fredweiliDec 12, 2025
132
所以你觉得自己也应该在大厂，对吧？怎么这么屈才呢？
|
 |
wenrouxiaozhuDec 12, 2025
133
@colourfulsai rebase 干啥(狗头🐶)...“每次 IDE 点点直接 git merge origin/dev”....
我喜欢用： git rebase origin/dev --autostash git pull origin --autostash --rebase |
|
wenrouxiaozhuDec 12, 2025
134
|
 |
meetthebestDec 12, 2025
135
8 年前端，开发至今，一直保持命令行操作 git ，感觉这些基础操作不能依赖 GUI,容易忘
|
|
wenrouxiaozhuDec 12, 2025
137
@NoKey 有人喜欢用自己名字做分支名，一直用同一个分支开发... timeline 里塞了一堆 Merge origin/dev 的记录...
|
 |
kphiiaDec 12, 2025
138
cherry pick 第一次了解还是在参与开源项目时才知道，提 PR 后让用 cherry pick 把其他长期维护分支也都提一遍，然后惊为天人
|
 |
JoeDHDec 12, 2025
139
别人还能呆到四十岁再从大厂出来然后找到下家，这种含金量我觉得你没必要酸别人懂不懂几个 git 命令
|
 |
VaspikeDec 12, 2025
140
没有 cherry-pick 我活不下去
|
|
VaspikeDec 12, 2025
141
@SWALLOWW 我在 dev 分支中有 commitA 和 CommitB, main 分支没有这两次提交, 现在线上需要立即有 commitA 的修改而不要 commitB 的修改, 那么:
1. 切换分支到 main 2. cherry-pick dev 分支的 commitA 3. 上线 main 分支 |
 |
chill777Dec 12, 2025
142
水货很多，我司 10 年老前端不知道 typescript 和 linux
|
|
xz410236056Dec 12, 2025
143
@MENGKE #107 你小瞧 GUI 了，你知不知道 GUI 也可以实现自定义操作，能用 GUI 不用只用 CLI 的都是保守派。
|
 |
realJamespondDec 12, 2025
144
分支改动太大，不能 rebase ，最后只能 cherry pick 一个一个 apply commit
|
 |
eepheeDec 12, 2025 via iPhone
145
这个帖子的评论里，我没有看到有人在刻意秀优越感，只看到有人一个劲地让别人不要秀优越感，笑死
|
 |
imxiaoiDec 12, 2025
146
一般都是多版本管理才用这个吧
|
 |
sth2018Dec 12, 2025
147
cherry pick 超级好用
|
 |
148
工作 10 年了，前 2 年用 svn 然后换了 git 一直用到现在，工作这么久没用过 cherry pick 我真的很抱歉。。
我们分支 feature dev test release hotfix tag master 这些分支都非常明确，也有严格的工作流不太会出现一次提交合并到多分个支上 我一直在用 sourcetree 我也觉得很好用啊，用命令我倒觉得有点麻烦。sourcetree 也是领导推荐用的，不过总是能看到用命令比 gui 高人一等的说法，能解决问题自己用着舒服不就好了吗。。 |
 |
lixileDec 12, 2025
149
不仅仅是多版本 仓库体量大 共同开发人员多 cherry-pick 的场景就应该确实存在
单仓单版本 维护人员少 估计就很少会用 cherry-pick 全部被 merge rebase 取代了 还有就是不要期待从 svn 简陋的转移过来大厂 git linux 基础技能 任重道远 我只能说这些人有他的生态位 但是跟你密切合作时 我就希望他别在这里工作 天天讲基础知识 心态会容易崩溃 |
 |
uniDec 12, 2025
150
我更好奇一个人七八个项目是怎么搞，一年七八个还是同时开发七八个？
|
|
bluehttDec 12, 2025
151
@wenrouxiaozhu #134 是啊，所以我怀疑他是用 vscode 之类的编辑器
|
 |
MENGKEDec 12, 2025
153
@xz410236056 #143 冲突吗，并不吧？习惯用 GUI 就可以不知道基本的命令了吗
|
 |
blirunDec 12, 2025
154
客户端不会命令还比较正常吧，服务端应该不正常
|
|
shm7Dec 12, 2025
155
@elron #117
148 和 108 楼已经写明了常见的分支工作流是怎么回事。gitlab 官方也是建议这么来的。不会用可以学。 cherry-pick 在某些开发环境异常繁杂的团队也许是有用的，比如你说的几十几百个分支情况。 在我看来，这就像很早先的 goto 语法，很快用到，但乱七八糟。 如果让你选，你想把项目搞成几十个 alive 分支乱起八糟的开发嘛。说白了，shit moutain + 业务开发压力特别大的团队，特别喜欢用。因为正常流程已经不起作用了。 |
|
shm7Dec 12, 2025
156
@wnpllrzodiac #57 > 分支修改了 50 个文件，只想提交其中的 20 个文件的改动,有命令么？
git add 把你的文件一个个加上，这些文件就会进入 stage 暂存模式，git commit 时候只会提交 stage 过的文件。 或者你直接用 gui 工具一个个点，更方便 |
|
wenrouxiaozhuDec 12, 2025
157
@bluehtt #151 不知道 add 有点抽象==...会不会好多人不知道工作区、暂存区
|
|
shm7Dec 12, 2025
158
@Vaspike #141 你也可以从 commitA checkout 出一个新分支，该分支可以 dev 平行的开发分支合并到 master ，还可以做点其他修改。PS 你还要把 master 也先合并到你这个分支，还要测试确认所有功能开发无误。
总之，用分支都是可以的。而且是 gitlab 官方更推荐的做法。草草把一个 hash 推到 master ，甚至连测试都没有。不符合推荐的上线流程。 |
|
shm7Dec 12, 2025
159
看了半天，都是些经验匮乏还喜欢论道，甚至在一些恶劣环境学了些歪门邪道，就以为是屠龙技 说别人不会以此炫耀 的东西。
怪不得程序员 35 岁会这么惨，拿着锤子个个是钉子，一个个天天问别人开展什么副业好抄袭取代之... |
|
160
@shm7 cherry-pick 从来不是复杂团队或者代码屎山才用，它本身就是 git 非常非常非常的常规能力。
如果一个人从来不用 cherry-pick ，我基本能判断他参与的项目规模和协作强度有限，你不要反驳，事实就是如此。 像你说的 gitlab 的推荐工作流，cherry-pick 和它并不冲突，反而是配套动作，挑选某个已验证的提交回拣到 release/hotfix ，本什就是标准发版维护的一部分，并不是项目烂到不行才会用。 总之就一句话，同一份改动、多条线受控落地，这就是 cherry-pick 的设计逻辑 |
 |
fendddddddaDec 12, 2025
162
你这个跟嘲笑 CEO 不会用 Excel 类似
|
 |
zuixinwenyueDec 12, 2025
163
平时都是用 idea 新建文件直接就已经 add 了，如果用命令的话，我都是直接 add ./ 。真没有使用命令去 add 单独的文件，我觉得这个无所谓吧 只要协作没有问题就可以了
|
 |
gcgj72Dec 12, 2025
165
八股文进去的 实际啥水平谁知道呢
|
 |
xppggDec 12, 2025
166
@nekoneko git reset --soft HEAD~1 在本地执行也算是回到了上一状态 在我理解也算是一种回滚操作,checkout restore 也可以, revert 确实更安全
|
 |
ckdxcDec 12, 2025
167
@iloveyou 感觉很多人, 都不会去研究这些按钮是干嘛的, 只用最基础的, cherry pick, 感觉只有那种一个仓库很多版本的项目才用的很, 如果是单一服务类型的, 就一套代码, 确实用不上, 大厂一般确实就一套代码, 因为自己就是甲方, 服务 C 端, 或者自己内部用
|
 |
ltmstDec 12, 2025
168
不会用 , 我都是手动复制过去的
 |
|
bluehttDec 12, 2025
169
@wenrouxiaozhu #157 idea 这种隐藏 stage 的策略也挺好的。提交、拉取能正常用就可以了，其他并不是必备技能。按照干活的角度来说，够用。
|
 |
admin948Dec 12, 2025
171
|
 |
bigShrimp8577Dec 12, 2025
172
@hangbale #63 前端又不是只有 app,不会抓包才是绝大部分
|
|
ckdxcDec 12, 2025
173
@manwhatcanisay 感觉完全 代码仓类型有关系, 如果是小仓库, 维护的人少, cherry pick 用的少, stash 就用得上, 如果是大仓库, 要同时维护 N 个分支, cherry pick 就用的多, stash 就有点吃力了, 我遇到大仓库, 开发压力大的时候, 就 多 clone 几个下来, 因为很多时候, 可能同时开发多个特性, 然后还有不同版本的问题需要定位, 切分支就麻烦很多了, 还有 git rebase 基本不用
|
|
ckdxcDec 12, 2025
174
@Lemonadeccc #65 合主分支得用 merge, 自己分支随便 rebase, 每次看自己提交乱乱的, 就习惯压缩一下, commit msg 也会重新编辑, 这些操作都用 IDEA 自带的工具呀, 谁还手动敲呀, 手动敲的最多的也就 clone checkout 啥之类的
|
|
ckdxcDec 12, 2025
175
@ckdxc #173 rebase 也用, 原来 GUI 里面的 压缩 交互式变基就是 rebase, 那一直都在用
 , 合主分支 merge, 自己分支 rebase |
 |
Terry05Dec 12, 2025
176
只会 ui 操作，平时不敲命令行是属于什么重大失误吗，会影响工作吗
|
 |
177
大厂的人也不全是厉害的。这都算小事了，往 git 里塞大文件，一个仓库膨胀成几十 G ，基本没法维护
再举个典型例子：“很多人找我，我发过去一篇文档，文档里写的都算小白了，又过来找我，然后我把文档直接截图给他，然后他就懂了” 很多人思想都僵化了，等着别人喂饭。我一般都不惯着，当然老板另说... |
|
edisonwongDec 12, 2025
178
所以我面试都会问
1. git 常用用法 2. git 如何各种情况下回滚 3. push 密码或大文件到远端后，后续还衍生出不同的 commit ，怎么解决 如果都能回答出来，很强，扎实，并且协同啥的应该也没啥问题。还是有一些不错候选人能答出来的 |
 |
lingxi27Dec 12, 2025
179
管他什么厂出来的，有得选的话我不会跟这种人做同事
|
|
wenrouxiaozhuDec 12, 2025
180
@ckdxc #173 “可能同时开发多个特性“ 这个用 worktree 好一点
|
 |
goodboy95Dec 13, 2025 via Android
182
说起来，我最开始用的是英文版的 tortoise git ，用着用着就对大部分的 git 命令有了概念，cherry pick 也好，amend 也好，或者 reflog, bisect 之类。然后稍微查一下这些命令的用法，就可以去命令行操作了。
|
 |
julyclydeDec 13, 2025
183
其实 cherry pick 本身也有问题
一般的 commit 都是提交的“一个版本”。而 cherry pick 它去 pick 的是“一部分补丁” |
 |
midsoloDec 13, 2025
184
@whoosy #120 这个情况我以前真的碰到过，公司对外号称是 SaaS 项目，实际上内部拉了几十个代码分支在做定制化开发，如果我要修复一个在每条分支上都存在的老 bug ，这个时候，cherry pick 就派上用场了
|
|
ckdxcDec 15, 2025
185
@wenrouxiaozhu #180 谢谢 好兄弟, 已经用上了, 节省了 150G 存储
|
 |
nicejerry666Dec 15, 2025
186
冷知识：大厂一线员工基本都是内包（本 7 年大厂内包路过）
|
|
wenrouxiaozhuDec 16, 2025
187
@ckdxc #185 😄
|
|
wenrouxiaozhuDec 16, 2025
188
@yustation #68 有 add -p,很好用,鼠标框选右键就行,看我#134 的回复👀
|
 |
gscsnmDec 19, 2025
190
别惊讶。快手出来的不熟悉 git 流
|
Select Language