Jason Pan

Git不是这么用

潘忠显 / 2021-12-27


本文罗列了 8 个常见的 Git 和工蜂的不恰当使用的案例,给出了简单描述、影响以及规避方法,涉及开发及分支管理。文末给出了几条使用 Git 的建议。常见的 Git 进阶使用示例,可以查看《Git 常用指令》。

文章中如有不妥之处欢迎大家评论指出,也欢迎补充你遇到的常见的不太合理的操作。

[TOC]

1. 直接推到 master 发起 Review

【描述】

image-20211224160045537

【影响】

直接影响主分支,无法控制主分支质量

【规避方法】

2. commit 信息无意义

【描述】

image-20211227145543994

【影响】

【规避方法】

commit 合理划分,尽量让每次 commit 的信息反应增删修改的内容。

3. 简单修改反复commit

【描述】

下边这个 MR 在两个位置共修改了 17 行,但是却进行了 6 次 commit

image-20211224160240452

【影响】

影响代码 review。如果 change 太多的,reviewer 可能选择分 commit 进行 review。这用情况下,会造成反复修改的点给 reviewer 带来困惑和重复的工作量。

【规避方法】

尝试使用操作,调整合并commit:

4. 收录构建结果

【描述】

要理解 Git 是一种“分布式版本管理”系统(DVCS),工蜂或者 Github 上的所有版本控制信息,在本地都会存一份。

将构建结果直接加入到版本管理中,导致仓库迅速增大。

下图就是为了说明,即使你在后来的 commit 中删除了大文件,其实在本地、远端依然存在着他之前的副本:

image-20211227113007822

【影响】

【规避方法】

5. 提 MR 之前 Pull/Merge 待合入分支

下边这个例子是实际中的一个场景:

  1. 绿色分支的产生,是从一次从红色分支叉出去,merge 进去了一个 commit,之后再没有 pull 或者 rebase 主分支
  2. 绿色分支 merge 之前的两次 commit 都已经被合并进了红色分支
  3. 红色分支中图合并了一些其他 commit
  4. 绿色分支 commit 一个 “优化”

这样绿色分支要合并到红色的分支 dev4.0 并提交 MR 时,会有两次 commit 要进行 Review:

image-20211224164037726

【影响】

多出额外的 N 次 commit,进而影响:

【规避方法】

image-20211227160223011

6. 分支管理者只使用 Merge

【描述】

不少分支管理的同学,在 Review 通过之后的 Merge 环节会直接点 Merge,这样会造成分支中大量的 Merge 信息、细粒度 commit 信息。

【影响】

多次 commit 既可以方便开发,也可以方便 review。但是,在合并到主干分支的时候:

【规避方法】

image-20211227123049793

image-20211227123223194

7. 单次 MR 内容太多

【描述】

一次 MR 提交太多内容,甚至涉及独立的多方面的修改。

有两种情况会造成这种现象:

【影响】

一次 MR 涉及的内容太多,不利于进行 Code Review:

【规避方法】

image-20211227144425025

8. 每有更新关闭并新开 MR

9. 本地复制多个目录开发

【描述】

担心修改错误,将一个仓库的目录拷贝多份,XXX、XXX.bak、XXX.20211225 等等,在不同的目录中做修改。

【影响】

【规避方法】

image-20211227150734115

0. 几点建议