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

git

repo

Code

branch

83 条回复 • 2021-05-07 08:36:16 +08:00

1

xujinkai

2021-04-27 12:25:50 +08:00 via Android

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

2

balabalaguguji

2021-04-27 13:40:40 +08:00

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

3

xbh1794970183564

2021-04-27 13:42:29 +08:00 via iPhone

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

4

wellsc

2021-04-27 13:43:51 +08:00

@balabalaguguji ？

5

hackyuan

2021-04-27 13:46:47 +08:00

@balabalaguguji ?

6

MonoBiao

2021-04-27 13:49:15 +08:00

@balabalaguguji ？

7

AndyAO

2021-04-27 13:51:38 +08:00

6

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

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

8

Mirage09

2021-04-27 13:57:54 +08:00

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

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

9

szdubinbin

2021-04-27 14:00:30 +08:00

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

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

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

10

clino

2021-04-27 14:01:13 +08:00

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

11

szdubinbin

2021-04-27 14:01:29 +08:00

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

12

kop1989

2021-04-27 14:02:54 +08:00

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

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

13

Taojun0714

2021-04-27 14:31:40 +08:00

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

14

mamili

2021-04-27 15:35:30 +08:00

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

15

mongodb

2021-04-27 15:38:06 +08:00

@kop1989 确实是看组织结构。

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

16

balabalaguguji

2021-04-27 17:22:57 +08:00

1

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

17

balabalaguguji

2021-04-27 17:26:08 +08:00

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

18

yhxx

2021-04-27 17:31:37 +08:00

@balabalaguguji

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

19

yhxx

2021-04-27 17:33:23 +08:00

8

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

20

balabalaguguji

2021-04-27 17:34:44 +08:00

2

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

21

sky123jk

2021-04-27 18:33:42 +08:00

字节貌似也是 git

22

Jooooooooo

2021-04-27 18:59:06 +08:00

啥叫大厂不用 git

多去几个大厂看看吧

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

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

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

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

23

cominghome

2021-04-27 19:11:33 +08:00

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

24

wellsc

2021-04-27 19:58:36 +08:00

@balabalaguguji perforce?

25

billlee

2021-04-27 20:16:36 +08:00

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

26

Augi

2021-04-27 21:29:28 +08:00 via iPhone

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

27

Augi

2021-04-27 21:31:11 +08:00 via iPhone

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

28

mooyo

2021-04-27 21:35:08 +08:00 via iPhone

@balabalaguguji ？

29

nvioue

2021-04-27 22:58:17 +08:00

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

30

huangsen365

2021-04-27 23:55:21 +08:00 via iPhone

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

31

namelosw

2021-04-28 00:09:53 +08:00

1

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

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

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

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

32

easylee

2021-04-28 00:26:41 +08:00

2

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

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

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

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

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

33

jsq2627

2021-04-28 01:58:49 +08:00 via iPhone

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

34

msg7086

2021-04-28 02:22:59 +08:00

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

35

cassyfar

2021-04-28 02:35:49 +08:00

@balabalaguguji

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

36

yzbythesea

2021-04-28 02:49:03 +08:00

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

37

yzbythesea

2021-04-28 02:53:02 +08:00

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

38

kaedea

2021-04-28 03:11:42 +08:00 via Android

没有

39

tsaohai

2021-04-28 03:19:05 +08:00 via iPhone

有人用过 source depot 吗😆😆😆

40

gaohongyuan

2021-04-28 03:37:44 +08:00

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

41

duhb

2021-04-28 06:42:36 +08:00 via iPhone

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

42

cassyfar

2021-04-28 07:10:14 +08:00

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

43

ladypxy

2021-04-28 07:39:11 +08:00 via iPhone

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

44

duhb

2021-04-28 07:54:44 +08:00 via iPhone

1

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

45

20015jjw

2021-04-28 07:57:24 +08:00 via Android

用 hg 的瑟瑟发抖

46

inhzus

2021-04-28 08:20:08 +08:00 via iPhone

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

47

zjsxwc

2021-04-28 08:21:11 +08:00 via Android

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

48

zjsxwc

2021-04-28 08:33:17 +08:00 via Android

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

49

zjsxwc

2021-04-28 08:46:20 +08:00 via Android

@zjsxwc

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

50

wangyzj

2021-04-28 09:12:44 +08:00

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

51

hcen1997

2021-04-28 09:19:13 +08:00

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

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

52

manami

2021-04-28 09:19:37 +08:00

1

My stupid boss still prefers SVN

53

hcen1997

2021-04-28 09:19:52 +08:00

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

54

hcen1997

2021-04-28 09:23:05 +08:00

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

55

verzqli

2021-04-28 09:26:05 +08:00

@yhxx
MD 绝了一摸一样

56

zjsxwc

2021-04-28 09:27:44 +08:00 via Android

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

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

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

svn 是集中式一整套系统，

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

57

balabalaguguji

2021-04-28 09:37:32 +08:00

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

58

balabalaguguji

2021-04-28 09:39:34 +08:00

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

59

balabalaguguji

2021-04-28 09:40:35 +08:00

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

60

balabalaguguji

2021-04-28 09:41:49 +08:00

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

61

LostPrayers

2021-04-28 09:47:54 +08:00

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

62

balabalaguguji

2021-04-28 09:49:38 +08:00

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

63

balabalaguguji

2021-04-28 09:51:40 +08:00

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

64

balabalaguguji

2021-04-28 09:54:49 +08:00

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

66

zjsxwc

2021-04-28 11:32:39 +08:00

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

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

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

67

vagranth

2021-04-28 12:04:42 +08:00

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

68

vagranth

2021-04-28 12:09:58 +08:00

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

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

69

vagranth

2021-04-28 12:14:47 +08:00

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

70

cassyfar

2021-04-28 18:05:03 +08:00

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

71

cassyfar

2021-04-28 18:06:02 +08:00

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

72

cassyfar

2021-04-28 18:06:58 +08:00

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

73

balabalaguguji

2021-04-28 18:18:12 +08:00

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

74

cassyfar

2021-04-28 18:28:37 +08:00

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

75

carrieflint

2021-04-28 18:42:31 +08:00

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

76

yhxx

2021-04-28 19:14:22 +08:00

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

77

LostPrayers

2021-04-28 20:23:15 +08:00

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

78

LostPrayers

2021-04-28 20:24:32 +08:00

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

79

cubecube

2021-04-29 00:57:09 +08:00

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

80

imjamespond2020

2021-04-29 10:36:16 +08:00 via Android

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

81

learningman

2021-04-29 11:18:51 +08:00 via Android

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

82

clino

2021-05-06 21:54:05 +08:00

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

83

namelosw

2021-05-07 08:36:16 +08:00

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