同事从大厂出来的，之前不知道 git add 可以提交部分文件，现在又听都没听过 cherry pick

[dumplingsK]

如题，非常不解。难道大厂没有版本管理么？咨询了一下，说是一个人七八个项目，根本没有时间管理。 压力这么大的么？

[urlk]

不会的自己去学 https://learngitbranching.js.org/?locale=zh_CN

cherry pick 是很基础的命令, rebase 也是基于 cherry pick 的

[nealHuang]

cherry pick 爽爆了，不过就是不好对比是否合并过

[Shaar]

@Shaar 搜了一下，这个功能 svn 也有，就是合并某个提交到当前分支嘛。。。这个经常用，不会用的真的有点奇怪了，一般都会拉分支的啊

[jzhm]

@Lemonadeccc #65 我用 rebase 多，但是我同事们用 merge 多

[ciki]

cherry pick 是真不知道，大多数时候根本用不上

[chimission]

说明他没什么技术追求， 单纯够用就行。。。。

[MENGKE]

@bryce1123 #29 原来最基本的 git 命令也成了八股文了，在你们看来什么不是八股文呢？

[shm7]

1 不用特别秀优越。
2 很多大厂用 gitlab 有刻板的分支流程，cherry pick 用的很少，都是从 main/master/dev 拉代码到 feature 分支，再合并回去，方便分支管理，和很多人共同开发时的秩序。
3 细碎工作很多+时间很忙的地方，才喜欢这里随便一个 hash 拉个分支出来，要是有 10 个人以上，分支 5 个以上，这种沟通维护成本显而易见的提升。

[KinBob]

看这个帖子浪费了宝贵的 5 分钟

[shm7]

不信的可以在这里搜下 https://git-scm.com/book/zh/v2 你们自认为很牛的 cherrypick 技术，被放在哪些旮旯里

[shm7]

@cocong #67 一般正经厂 release 后都要打上 tag 的，标记开发的功能，要拉从指定 tag 拉就行了，也能知道代码的 base 能力。

[Cu635]

看个人表现吧，是说非常不屑的那种“不知道”，还是一脸懵的那种“不知道”，还是说有点意外、有点小“震惊”（或者类似情绪）的不知道。

大厂因为老员工比例高一点，作为组长也好作为上司也好，如果是它们拒绝新事物，不使用版本管理工具，或者只是作为摆设，或者其它类似情况的话，加上底下员工工作压力这么大，员工确实有可能被挤压的没精力去了解一些基础知识。

@aiwoshishen #4
不一定，大厂本部也不一定好哪里去

[holy_sin]

大厂重视的是道 你这都是术 哈哈

[bluehtt]

@mxT52CRuqR6o5 #22 帖子说的是 git add ，你说的是 git commit 。不过使用 idea 的时候，默认情况下，流程里已经很少看到 add 这步了，我修改文件后，按 esc 退出默认就是 add 。我喜欢使用 git 命令行，操作最多的也是 cherry pick 、rebase 、git flow 这种，很少会需要手动 git add 。

楼主用的可能是一些编辑器，vscode 、trae 之类的，修改之后还需要使用者手动 add 一下。个人使用的时候没有这个 git add 的需求。

[zhengfan2016]

@liuliuliuliu 可能是真的，我上家公司的大厂老程序员，基本都是 30-40 ，它们用 git 基本不 review 哪些和本次提交无关的，直接全部提交的，可能这就是高级程序员的从容吧

[lynan]

我喜欢用 GitHub Desktop ，简单流畅

[elron]

@shm7 #111 你的意思是如果我在 develop 分支修了一个涉及较多文件的 bug ，线上版本还需要手动逐个复制修改？捞不捞啊，cherry-pick 神技被你贬低的一文不值，你要去银行开发，一个仓库几百个分支让你一个一个手动复制去吧

[Desdemor]

cherry pick 好用爱用，但是不能说明一个人的水平高低，顶多是横向涉猎不多

[LXchienne]

这非常符合程序员刻板印象，关注工具和技术，离业务太远，挣钱才是王道

[whoosy]

@shm7 #110 一个仓库只有主线分支无所谓，想怎么弄怎么弄，就怕那种几十个分支对应几十个客户的项目，修一个共性问题，不可能每个分支都手动复制粘贴，cherry-pick 就是干这个事的

[paceewang1]

git 不知道怎么读？那 github 你总知道吧，`gay`hub

[unco020511]

不可能工作这么多年不知道 cherry-pick 的吧,我感觉只要是项目复杂一点,就经常会用到 cherry-pick.其实 gui 和 cli 差别没那么大的,我更习惯用 gui.但是说在大厂不知道 add 和 cherry-pick,那就确实是够离谱的

[joinmouse]

可能不用命令行操作，能快速熟悉就好了

[dongdongdong]

经常用 cherry-pick ，有些东西不发版，有些东西发版，可以挑出来，非常好用

[liuliuliuliu]

@zhengfan2016 从~从~容~容~游~刃~有~余~后面忘了...

[xz410236056]

@iloveyou 哪个 GUI 客户端没遴选这玩意。

[windmilll]

40 岁不知道这些倒显得合理了，如果是 20 多岁的年轻程序员我觉得不正常

[mxT52CRuqR6o5]

@bluehtt #114 add 不就是为了选择性地 commit 文件吗？

[jaxjaxjax]

cherry-pick 这个我印象很深，翻译成中文就是“摘樱桃”，每个 commit 都是一个樱桃，git cherry-pick commit-id 就是摘取对应 commit-id 的樱桃哈哈

[Mandelo]

@iloveyou 看来你也不用知道，右键提交列表可以选择 cherry pick

[SWALLOWW]

不是，到底有没有人介绍下 cherry-pick 是干啥的

[fredweili]

所以你觉得自己也应该在大厂，对吧？怎么这么屈才呢？

[wenrouxiaozhu]

@colourfulsai rebase 干啥(狗头🐶)...“每次 IDE 点点直接 git merge origin/dev”....
我喜欢用：
git rebase origin/dev --autostash
git pull origin --autostash --rebase

[wenrouxiaozhu]

@bluehtt 除了 add(VSCode 里只框选一部分->右键->暂存所选范围)，任何其他操作都用命令行....

[meetthebest]

8 年前端，开发至今，一直保持命令行操作 git ，感觉这些基础操作不能依赖 GUI,容易忘

[Yukiteru]

@jonsmith 确实解决冲突了

[wenrouxiaozhu]

@NoKey 有人喜欢用自己名字做分支名，一直用同一个分支开发... timeline 里塞了一堆 Merge origin/dev 的记录...

[HaibaraDP]

cherry pick 第一次了解还是在参与开源项目时才知道，提 PR 后让用 cherry pick 把其他长期维护分支也都提一遍，然后惊为天人

[JoeDH]

别人还能呆到四十岁再从大厂出来然后找到下家，这种含金量我觉得你没必要酸别人懂不懂几个 git 命令

[Vaspike]

没有 cherry-pick 我活不下去

[Vaspike]

@SWALLOWW 我在 dev 分支中有 commitA 和 CommitB, main 分支没有这两次提交, 现在线上需要立即有 commitA 的修改而不要 commitB 的修改, 那么:
1. 切换分支到 main
2. cherry-pick dev 分支的 commitA
3. 上线 main 分支

[chill777]

水货很多，我司 10 年老前端不知道 typescript 和 linux

[xz410236056]

@MENGKE #107 你小瞧 GUI 了，你知不知道 GUI 也可以实现自定义操作，能用 GUI 不用只用 CLI 的都是保守派。

[realJamespond]

分支改动太大，不能 rebase ，最后只能 cherry pick 一个一个 apply commit

[eephee]

这个帖子的评论里，我没有看到有人在刻意秀优越感，只看到有人一个劲地让别人不要秀优越感，笑死

[imxiaoi]

一般都是多版本管理才用这个吧

[sth2018]

cherry pick 超级好用

[wxm]

工作 10 年了，前 2 年用 svn 然后换了 git 一直用到现在，工作这么久没用过 cherry pick 我真的很抱歉。。
我们分支 feature dev test release hotfix tag master 这些分支都非常明确，也有严格的工作流不太会出现一次提交合并到多分个支上
我一直在用 sourcetree 我也觉得很好用啊，用命令我倒觉得有点麻烦。sourcetree 也是领导推荐用的，不过总是能看到用命令比 gui 高人一等的说法，能解决问题自己用着舒服不就好了吗。。

[lixile]

不仅仅是多版本 仓库体量大 共同开发人员多 cherry-pick 的场景就应该确实存在
单仓单版本 维护人员少 估计就很少会用 cherry-pick 全部被 merge rebase 取代了
还有就是不要期待从 svn 简陋的转移过来大厂 git linux 基础技能 任重道远 我只能说这些人有他的生态位
但是跟你密切合作时 我就希望他别在这里工作 天天讲基础知识 心态会容易崩溃

[uni]

我更好奇一个人七八个项目是怎么搞，一年七八个还是同时开发七八个？

[bluehtt]

@wenrouxiaozhu #134 是啊，所以我怀疑他是用 vscode 之类的编辑器

[onll42y]

@YsHaNg 那还得是 git rebase -i

[MENGKE]

@xz410236056 #143 冲突吗，并不吧？习惯用 GUI 就可以不知道基本的命令了吗

[blirun]

客户端不会命令还比较正常吧，服务端应该不正常

[shm7]

@elron #117
148 和 108 楼已经写明了常见的分支工作流是怎么回事。gitlab 官方也是建议这么来的。不会用可以学。

cherry-pick 在某些开发环境异常繁杂的团队也许是有用的，比如你说的几十几百个分支情况。

在我看来，这就像很早先的 goto 语法，很快用到，但乱七八糟。

如果让你选，你想把项目搞成几十个 alive 分支乱起八糟的开发嘛。说白了，shit moutain + 业务开发压力特别大的团队，特别喜欢用。因为正常流程已经不起作用了。

[shm7]

@wnpllrzodiac #57 > 分支修改了 50 个文件，只想提交其中的 20 个文件的改动,有命令么？

git add 把你的文件一个个加上，这些文件就会进入 stage 暂存模式，git commit 时候只会提交 stage 过的文件。
或者你直接用 gui 工具一个个点，更方便

[wenrouxiaozhu]

@bluehtt #151 不知道 add 有点抽象==...会不会好多人不知道工作区、暂存区

[shm7]

@Vaspike #141 你也可以从 commitA checkout 出一个新分支，该分支可以 dev 平行的开发分支合并到 master ，还可以做点其他修改。PS 你还要把 master 也先合并到你这个分支，还要测试确认所有功能开发无误。
总之，用分支都是可以的。而且是 gitlab 官方更推荐的做法。草草把一个 hash 推到 master ，甚至连测试都没有。不符合推荐的上线流程。

[shm7]

看了半天，都是些经验匮乏还喜欢论道，甚至在一些恶劣环境学了些歪门邪道，就以为是屠龙技 说别人不会以此炫耀 的东西。

怪不得程序员 35 岁会这么惨，拿着锤子个个是钉子，一个个天天问别人开展什么副业好抄袭取代之...

[elron]

@shm7 cherry-pick 从来不是复杂团队或者代码屎山才用，它本身就是 git 非常非常非常的常规能力。

如果一个人从来不用 cherry-pick ，我基本能判断他参与的项目规模和协作强度有限，你不要反驳，事实就是如此。

像你说的 gitlab 的推荐工作流，cherry-pick 和它并不冲突，反而是配套动作，挑选某个已验证的提交回拣到 release/hotfix ，本什就是标准发版维护的一部分，并不是项目烂到不行才会用。

总之就一句话，同一份改动、多条线受控落地，这就是 cherry-pick 的设计逻辑

[whoosy]

@shm7 #158 你这真是歪门邪道，别教坏其他人了，三路合并是你这样用的？不想评价

[fenddddddda]

你这个跟嘲笑 CEO 不会用 Excel 类似

[zuixinwenyue]

平时都是用 idea 新建文件直接就已经 add 了，如果用命令的话，我都是直接 add ./ 。真没有使用命令去 add 单独的文件，我觉得这个无所谓吧 只要协作没有问题就可以了

[nekoneko]

@xppgg git 的回滚是 revert , reset 是重置

[gcgj72]

八股文进去的 实际啥水平谁知道呢

[xppgg]

@nekoneko git reset --soft HEAD~1 在本地执行也算是回到了上一状态 在我理解也算是一种回滚操作,checkout restore 也可以, revert 确实更安全

[ckdxc]

@iloveyou 感觉很多人, 都不会去研究这些按钮是干嘛的, 只用最基础的, cherry pick, 感觉只有那种一个仓库很多版本的项目才用的很, 如果是单一服务类型的, 就一套代码, 确实用不上, 大厂一般确实就一套代码, 因为自己就是甲方, 服务 C 端, 或者自己内部用

[ltmst]

不会用 , 我都是手动复制过去的

[bluehtt]

@wenrouxiaozhu #157 idea 这种隐藏 stage 的策略也挺好的。提交、拉取能正常用就可以了，其他并不是必备技能。按照干活的角度来说，够用。

[cnzmz]

@iloveyou 用图形界面也正常，图形界面也支持 cherry pick ，应该也也能看到这个功能吧。

[admin948]

@MENGKE #153 看我上面举例子的那个同事，他就是用的 GUI 。

不知道命令行，基本原理得知道吧？

行，原理也是八股文。

那么至少哪个图标是干嘛的得知道吧？

[bigShrimp8577]

@hangbale #63 前端又不是只有 app,不会抓包才是绝大部分

[ckdxc]

@manwhatcanisay 感觉完全 代码仓类型有关系, 如果是小仓库, 维护的人少, cherry pick 用的少, stash 就用得上, 如果是大仓库, 要同时维护 N 个分支, cherry pick 就用的多, stash 就有点吃力了, 我遇到大仓库, 开发压力大的时候, 就 多 clone 几个下来, 因为很多时候, 可能同时开发多个特性, 然后还有不同版本的问题需要定位, 切分支就麻烦很多了, 还有 git rebase 基本不用

[ckdxc]

@Lemonadeccc #65 合主分支得用 merge, 自己分支随便 rebase, 每次看自己提交乱乱的, 就习惯压缩一下, commit msg 也会重新编辑, 这些操作都用 IDEA 自带的工具呀, 谁还手动敲呀, 手动敲的最多的也就 clone checkout 啥之类的

[ckdxc]

@ckdxc #173 rebase 也用, 原来 GUI 里面的 压缩 交互式变基就是 rebase, 那一直都在用 , 合主分支 merge, 自己分支 rebase

[Terry05]

只会 ui 操作，平时不敲命令行是属于什么重大失误吗，会影响工作吗

[edisonwong]

大厂的人也不全是厉害的。这都算小事了，往 git 里塞大文件，一个仓库膨胀成几十 G ，基本没法维护

再举个典型例子：“很多人找我，我发过去一篇文档，文档里写的都算小白了，又过来找我，然后我把文档直接截图给他，然后他就懂了”

很多人思想都僵化了，等着别人喂饭。我一般都不惯着，当然老板另说...

[edisonwong]

所以我面试都会问
1. git 常用用法
2. git 如何各种情况下回滚
3. push 密码或大文件到远端后，后续还衍生出不同的 commit ，怎么解决

如果都能回答出来，很强，扎实，并且协同啥的应该也没啥问题。还是有一些不错候选人能答出来的

[lingxi27]

管他什么厂出来的，有得选的话我不会跟这种人做同事

[wenrouxiaozhu]

@ckdxc #173 “可能同时开发多个特性“ 这个用 worktree 好一点

[YsHaNg]

@yustation 我没用过 ide git 从来都是 terminal

[goodboy95]

说起来，我最开始用的是英文版的 tortoise git ，用着用着就对大部分的 git 命令有了概念，cherry pick 也好，amend 也好，或者 reflog, bisect 之类。然后稍微查一下这些命令的用法，就可以去命令行操作了。

[julyclyde]

其实 cherry pick 本身也有问题
一般的 commit 都是提交的“一个版本”。而 cherry pick 它去 pick 的是“一部分补丁”

[midsolo]

@whoosy #120 这个情况我以前真的碰到过，公司对外号称是 SaaS 项目，实际上内部拉了几十个代码分支在做定制化开发，如果我要修复一个在每条分支上都存在的老 bug ，这个时候，cherry pick 就派上用场了