之前也没用过 cherry pick ，但自从接了一个美国 remote ，master 分支和 dev 分支差了几百个版本的时候，我才知道 cherry pick 这个东西。。。

大厂有自己的版本管理系统。比如微软有 source depot ，那时候还没 git 呢。 https://corengen.wordpress.com/2007/03/20/what-does-microsoft-use-for-source-control/ 这几年换成 git 了 https://news.ycombinator.com/item?id=44253212

虽然震惊，但能理解。 一方面 git add 如果平时都用 IDE ，从没用过也是可能的，而大厂都是微服务架构，大多 repo 就是一个或者几个人在负责，没有复杂的多人协作场景没用过 cherry-pick 也正常。 另一方面大厂重要的是能理解业务能推动流程能扩大 scope ，不少人对技术细节非常不在意，或者说技术水平只占工作能力的很小一部分，这种人能在大厂混反而更可能具备结果思维。

一个人七八个项目，有可能都是微服务吧，微服务好多都是一个人开发提交，连代码评审都没得，全依赖自动化审查和测试，这种确实用不到，平时就是 git add .就行了，也没什么冲突，有问题直接 revert 就行了。 以前有个要求是必须至少两个人同意代码才能合并，实际执行就是两个项目的开发友好互评

@HusaYn 给特

部分提交的意思是一个文件修改了 50 行。只提交 20 行修改？ 如果改了 5 个文件，提交 3 个文件的修改。那不入职就该知道。

遴选确实很少用啊，不都是自己的分支最终合并主分支

我有个需求，分支修改了 50 个文件，但是有很多提交记录，反复修改，是个大 feature. pr 只想提交其中的 20 个文件的改动,有命令么？ 我写了个脚本做这个，用的次数还挺多。一个大 feature 要拆几个 review,不然肯定没人愿意看

@dongdongdong 那是乱读吧，gIt 中间读类似 yie https://www.bbc.co.uk/learningenglish/chinese/features/pronunciation-tips-short-vowels/shortvowel1

哪个大厂？讲道理大厂应该不至于