一般大厂应该怎样做 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 ？）最合适？

求各种细节

[xujinkai]

不是大厂 感觉可以参考一些大型的开源项目

[balabalaguguji]

真正的大厂，重要项目不会用 Git 吧，没办法做权限控制，反正我知道的 OPPO，网易都是用 SVN

[xbh1794970183564]

1.每次 cr 都会组内直接视频会议来进行，大概十几个人看你的代码
2.和你说的差不多
3.没听懂

[wellsc]

@balabalaguguji ？

[hackyuan]

@balabalaguguji ?

[MonoBiao]

@balabalaguguji ？

[AndyAO]

有些大厂的内部项目就是不怎么用 Git，不过很多人不清楚

《 Google 和 Facebook 为什么不用 Git 管理源码？》
https://mp.weixin.qq.com/s/rVMCi8oDGdD5OsJnQlyL5g

[Mirage09]

1. 有错直接在 CR 上 comment 呗，还能怎么样。。
2. 我们组是直接 clone 到本地，然后提 cr，最后 merge 到主 branch，当然也有人开自己的 branch 去做一些 feature 和 testing
3. 没看懂

另外就我所知，Amazon 和微软都用 git （可能有些组不用？）上面有人说的 G/F 没去过，不知道

[szdubinbin]

1，首先你合入 master 肯定要跑 ci，确保你的代码首先没有致命问题导致不能编译并用自动化工具检查代码规范，js 就 eslint，提交 code review 的 commit 在有问题的地方评论就可以了，最后打回去修改，再提，这样。

2，开源项目是后者，公司 git 肯定不是所有人有 master 权限，大家开发完提交走上面的 1 过程后有导师 /有 master 权限合入

3，这个有一些规范，但没有强制，一般定义一个前缀，feature/fix/style 之类的，后面的看团队风格，下划线，横线我都见过，一般带项目信息，或者日期，个人 id 之类的，这个没有固定。

[clino]

Android 参考: https://android-review.googlesource.com/

[szdubinbin]

写错，上面是 branch 规范，commit 规范，跟上面差不多其实，看团队怎么定的。

[kop1989]

个人喜欢：
1 、直接写在代码注释里。
2 、3 这个跟公司组织结构，以及管理规范有关。有的只是取舍，没有一个最优解。

就跟楼上 git 和 svn 的讨论一样。
git 和 svn 代表着版本管理的两个思路和方向，git 是分布式，svn 是集中式。
这两个并没有优劣之分，只有适合与不适合。

[Taojun0714]

用 gerrit 代码审核那套流程，所有人都 git pull reabse, 不随意增加 git commit

[mamili]

用 gerrit 加 comment，Git 只用来提交，rebase 到一次 Git commit 上。
gerrit 再触发 CI

[mongodb]

@kop1989 确实是看组织结构。

比如我现在最喜欢的模式是各自平时用 git， 但最后到了 ci /cd 流程简直跟进了 svn 一样，一个一个排队慢慢审。这是我这最合适的一种方式。

[balabalaguguji]

@wellsc
@hackyuan
@MonoBiao
不管你们是否承认，这就是事实，权限控制大过天，大厂的开源项目用 Git 很正常，内部项目不用 SVN 怎么做权限控制，或者一个项目 100G 的，用 Git 怎么管理，每个人都 clone 到自己电脑 100G

[balabalaguguji]

@kop1989 #12 是的，一个正确的认识：git 和 svn 代表着版本管理的两个思路和方向，git 是分布式，svn 是集中式。
这两个并没有优劣之分，只有适合与不适合。

[yhxx]

@balabalaguguji

OPPO 我不知道，网易都是用 SVN ？？？

[yhxx]

话说我们 code review 的日常：
"xxx，马上要发布了，这个 CR 帮我点一下"
"点了"

[balabalaguguji]

@yhxx #18 网易是的，因为我在里面工作时就是用 SVN 。OPPO 用的是 SVNBucket 定制版本，我是 SVNBucket 开发者。

[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 」

[duhb]

@cassyfar 他说的没问题，是你不懂而已。git 之所以快很大一部分就是因为全量 clone，多去看看 git pro

[cassyfar]

@duhb 我当然知道 git 是全量 clone 。但是一个 git repo 有 100G ？你知道 100G 的代码能有多少行吗？真有 100G，你知道要编译多久吗？ Linux kernel 这种巨无霸才 100 多 M 。

[ladypxy]

@balabalaguguji 用 git 也可以做权限控制啊。你可以 commit，但是你无权 merge

[duhb]

@cassyfar 我不知道，我只知道上面那哥们说的 git 原理没有问题。一个项目的形成不是只有代码还有很多静态资源。所以 100G 的项目不是没有，只是你没见过，没见过还拒绝承认它的存在，这就是你的认知。

[20015jjw]

用 hg 的瑟瑟发抖

[inhzus]

1. 直接评论提出修改意见，直到全部修改通过才点通过
2. 从 master 拉出 feature 分支，各种环境用 release 分支（解决多个分支同时发布的问题）测试、发布，最后线上全量发布后自动合入 master
3. commit 无所谓，只要用 to #xxxx 的形式指明需求、任务的 id，大多数人完成一个小功能、或者一天的就 commit 一次，最后效能平台能从 commit 回溯到需求就可

[zjsxwc]

@ladypxy 他说的权限应该是更细化的权限，比如对项目里面某个文件、某个子目录是否可以访问的权限吧

[zjsxwc]

@zjsxwc 只能用 submodules 加内网 ip 网络访问控制，来实现类似对某个子目录读写权限。

[zjsxwc]

@zjsxwc

gitlab 这种可以对项目 private 来控制其用户是否项目可被读取可被克隆，所以 submodules 加上类似 gitlab 的 private 就能满足细化权限控制。

[wangyzj]

1. 你确定你会认真去 review 么？这一直是我的理想
2. gerrit 就不说了
gitlab 就 gitflow 就行
3. commit 以单个可用完整功能吧

[hcen1997]

感谢 @zjsxwc 提出了 gitlib 也有权限控制. 是的 是这样的, gitlib 有权限管理, 针对分支提交做权限控制
超级大厂, 内部的架构其实问不出来的, 因为大家入职都签了保密协议不是吗?

倒是有 google 的离职程序员介绍谷歌内部工具, 基本都是找开发满足 google 内部的需求(比如面对上亿行代码怎么快速查找, 上百个人项目组怎么交流信息.)

[manami]

My stupid boss still prefers SVN

[hcen1997]

开源又不是共产主义, 哪里那么简单

[hcen1997]

不好意思 53 楼的意思时 开源和开放信息获取不是一个意思

[verzqli]

@yhxx
MD 绝了 一摸一样

[zjsxwc]

@zjsxwc 轻量级的 gogs 也支持每个用户私有仓库。

所以 git 与 svn 没什么不同都能满足企业需求，区别是 svn 是全套，而 git 需要配合 gogs/gitlab 来用，

svn 按文件来比较直白，而 git 是按元数据整体管理。

svn 是集中式一整套系统，

而 git 抛开 gogs/gitlab 来说仅仅只是一个命令行工具，与 ls 这种命令没有区别，ssh 加 git 就变成了 git 服务器，linux 用户管理（ chown，chmod ）加 ssh 加 git 就变成了有各种用户读写权限管理的 git 版本管理系统。

[balabalaguguji]

@namelosw #31 很显然你没熟悉过 SVN，拖后腿这种话都说得出

[balabalaguguji]

@nvioue #29 这才是正确的认识。只是现在很多新人一开始就是学 Git 的，SVN 没怎么用过，然后就有了各种鄙视

[balabalaguguji]

@Jooooooooo #22 估计你是一开始就用 Git 的，SVN 没用过吧，不然怎么会问啥叫权限控制。

[balabalaguguji]

@huangsen365 #30 嗯，是的，不过太难了，一个项目要拆分成多个仓库，管理也麻烦

[LostPrayers]

@cassyfar 举个例子，一些编译好的 lib 目录，动不动就是上 G 的，项目一多，再加上其他非代码资源，上百 G 不是很正常吗

[balabalaguguji]

@cassyfar #42 你以为的版本管理是只能存放代码，SVN 是二进制也能处理好的，以前做游戏，美术资源、策划文档，全部都是直接丢 SVN 里面，可以做版本管理，查看每次修改，不是你以为的只有纯文本

[balabalaguguji]

@ladypxy #43 显然是没用过 SVN 的，权限控制都不知道是什么，SVN 是可以文件级权限控制呀，设置每个人对文件的读写权限

[balabalaguguji]

@zjsxwc #47 是的，很多人连 SVN 的文件级权限控制都不知道，都还没了解过就开始喷

[zjsxwc]

git 分布式的好处是分支合并特别方便轻量，并且由此引发出了各种基于分支协作的工作模式，坏处是没有到某一个文件的权限管理。

svn 集中式好处是可以有到某一个文件的权限管理，坏处是开分支成本很高，合并分支也卡。


个人来说如果已经习惯了 git 各种分支工作模式，就会对使用 svn 体验有抵触，分支多就卡，合并也卡，解决分支冲突也卡，没有 git 那种舒服，我以前用 svn 都不怎么敢开分支，每次 svn 分支合并简直是噩梦。

[vagranth]

我司用 gitlab 的，提交代码用的是 Merge Request，在 commit comment 上写明 reviewer，然后 reviewer 直接在 MR 上做 comment，提交者需要处理完所有 comment 才可能会被允许 merge

[vagranth]

我同意 @kop1989 的说法，git 和 svn 两者没有优劣之分，只有适用场景不同（集中式 /分布式）。

不要说这俩了，即使是现在使用率已经很低的一些 version control 工具，在其出现时的背景，其存在都是有意义的。

[vagranth]

对于问题 2，如果用 git，请使用分布式思维方式，每个开发人员 fork 出来自己的工程，修改完后把需要 merge 的 patch 发 PR/MR 给 reviewer，在 reviewer 确认后，由主仓库维护者 merge 。主仓库不应该让所有人有写权限。
对于问题 3，commit 应该对应 comment，我觉得以 function 分比较适合。如果以 class 分，我想可能会出现编译不过的情况吧。commit 不能 break CI 。

[cassyfar]

@balabalaguguji 题主在谈程序员使用 git，你在这儿谈游戏，美术？？

[cassyfar]

@duhb 网站静态资源存 git repo ？贵司水平高得离谱。

[cassyfar]

@LostPrayers 太厉害了，贵司 git repo 直接编译的 lib 也放？你这是瞎用 git 好吧。

[balabalaguguji]

@cassyfar #72 认知狭隘了吧，这种需求难道不是很正常吗？我用 SVN 就随便丢这类二进制文件

[cassyfar]

@balabalaguguji 一种是认知狭隘，一种是菜得离谱。我也算 7 年码农了，大厂呆过，真没见过这种百 G repo，今天算是开眼了。

[carrieflint]

@cassyfar 如果 kernel 是「巨无霸」，那这让 chromium 情何以堪😅

[yhxx]

@balabalaguguji
确认了一下，除了一些游戏部门因为历史原因还在用 svn 之外，网易绝大部分部门已经都在用 git 了

[LostPrayers]

@cassyfar 所以才是 svn 和 git 混用。那堆依赖的 lib 也不可能谁都去编译一遍

[LostPrayers]

@cassyfar 另外谁告诉你只有 web 项目才有静态资源的。。。

[cubecube]

@balabalaguguji 内部项目也没那么重要，信息安全可以通过别的方式保证。
svn 管理大的 repo，是灾难

[imjamespond2020]

思维不同，svn 是大一统管理一个公司一个超大项目，git 是分而治之，很多个小项目，几个人开搞

[learningman]

@carrieflint chromium 只 pull 最新 commit 6G，还包括 third party，啥业务能有 chromium 的复杂度？

[clino]

@namelosw Google 咋不用 git 呢，Gerrit 都是 Google 开发的。

[namelosw]

@clino 我理解 Google 的主 Repo 用的版本管理是他们自己开发的一个东西，不是 git，git 代码量太大的时候性能跟不上，他们的 monorepo 应该有几十亿行