一般大厂应该怎样做 code review，如何组织 Git

[8e47e42]

求有实战经验党讲讲：
1. Code Review 作为 Senior SE 的流程怎么做会比较能帮助到 junior SE ？如果一个 PR 有 bug/错误 /需要改进的地方，我要如何提出比较好。
2. 一般大厂的大家如何使用 git 协作？会直接在同个 code base 上协作（一个 git repo, 小组所有人有读 /写权限，遇到 feature 直接创建 branch，commit 到 repo，完成以后 PR 到 master/main ），还是通常会从主 repo 中 fork->创建一个 branch 写这个 feature->PR 回去
3. Commit 以什么方式组织（ function ？ class ？）最合适？

求各种细节

[sky123jk]

字节貌似也是 git

[Jooooooooo]

啥叫大厂不用 git

多去几个大厂看看吧

还有啥权限控制以为 git 没有?

回到楼主的问题, 有错一般就是直接写评论.

协作一般会有 master 主分支, 开发再从主分支拉出去然后再有 develop, test 之类的分支提供测试发布, 最后 pr 合并上线

commit 一般按照需求组织, 一个需求是一个完整的 commit

[cominghome]

@balabalaguguji OPPO 互联网这边也是用 git，研发体系那边好像确实没用

[wellsc]

@balabalaguguji perforce?

[billlee]

1. 看个人习惯，我习惯直接在代码行上添加评论
2. 一般是 branch & merge, 没必要 fork
3. 按需求或特性组织

[Augi]

@balabalaguguji 刷新认知，待过腾讯，美团和一家外企都用的是 git，用 svn 是在大学的时候，有点刀耕火种的意思。。。

[Augi]

@balabalaguguji git 为啥没有权限控制，各家都是以 git 为基础实现自己的 code 平台。

[mooyo]

@balabalaguguji ？

[nvioue]

服了服了,到处都是 git 狂热粉丝, 一说 svn 就开始嘲讽... 一个管理代码的东西有啥吵的?
git 发明之前代码难道是外星人管理的?
有很多老一点项目和游戏行业都是用 svn 的,
现在的人不要以为 GitHub 流行了就觉得全世界都要用 git, 这不二极管么..
git 没有很 nb, svn 也不是垃圾; 你们 svn 的 git 的区别都没了解过吧..
过去吵 os 谁牛逼, 吵语言谁牛逼, 现在又来一个吵 git 和 svn 牛逼..

[huangsen365]

只要是大厂还没全部把相应项目拆分成为绝对的各种微服务架构…如果全部百分百是微服务架构的话使用 git 去做版本控制就一点也不永担心权限问题

[namelosw]

@balabalaguguji 你这个有点过于利益相关了

我理解 Amazon 和 Microsoft 这些大厂是用 Git 的。

Google 和 FB 不用 git 的原因是因为性能，Mercurial 本质上和 Git 更像，而不是 SVN 。至于这两家需要特殊的工具是因为他们走的是 Monorepo 路线，一个代码库有上亿行代码，其他体量不够或者 Polyrepo 路线的大厂都是 Git 。

我理解的确可能有些场景更适合 SVN，但是基本都是非技术驱动的敏感行业（军队，金融等等传统行业），而不是互联网大厂，因为我的经验就是 SVN 很拖开发后腿。

[easylee]

我曾经也觉得 git 是主流，是明智之选。

我主要做 Java 开发，以我当时的观念，举个例子就像是 spring mvc 对比 spring boot 。

后来随着负责的项目越来越多，考虑方面越来越多，发现我的想法其实是不成熟的，是错的。

没有孰优孰劣，只有适合不适合。

具体缘由前面的评论已经说的挺详细。

[jsq2627]

老实说，直到近期工作接触了一个百人协作，数万 commit 的 monorepo 后，才发现 git 的上限在哪里

[msg7086]

权限控制大过天，这很中国。
我厂每个开发都能看到所有的 Git 项目，能读所有项目的源码，能克隆所有的项目到本地。
当然我厂比较小，连微软我们都比不上，更别提网易之类世界一流的大厂了。

[cassyfar]

@balabalaguguji

clone 一下 100G ？？？你确定你在大厂当过程序员？

[yzbythesea]

1. 有错误就直接 comment 在 PR 上
2. 创建 branch 然后 merge 进 master
3. Commit 的范围比较宽松，基本以一个 feature 为主。

[yzbythesea]

现在都流行 microservice 了。。。哪还需要 svn 呢？意思是公司屎山一样的 monolith code 还可以吹一波？

[kaedea]

没有

[tsaohai]

有人用过 source depot 吗😆😆😆

[gaohongyuan]

> 1. Code Review 作为 Senior SE 的流程怎么做会比较能帮助到 junior SE ？如果一个 PR 有 bug/错误 /需要改进的地方，我要如何提出比较好。

直接在 PR 里评论，评论就是干这个用的。比如「这段代码可以用 XX 这个 API 实现」，「拼写错误 /错别字」，「这里最好这么写 XXX 」。如果一两句话很难讲清楚的话可以私聊或者面对面沟通

> 3. Commit 以什么方式组织（ function ？ class ？）最合适？

我在组里的经验：commit 不宜过大，所有东西加在一起尽量不要超过 500 行。如果超过了，可以尝试拆分成多个小 commit 。只要你能一句话概述这个 commit 在做什么，就可以当作一个 commit 。概述可以是
* 「重构某某 API (step 1)：给新 API 创建 interface 」
* 「重构某某 API (step 2)：实现新 API 里的 A 功能」
* 「重构某某 API (step 3)：实现新 API 里的 B 功能」
* 「重构某某 API (step 4)：让 Caller 调用新的 API 」
* 「重构某某 API (step 5)：清理旧的 API 」