--- theme: github highlight: a11y-dark --- 作者介绍 > 河畔一角，货拉拉资深工程师，主要负责货拉拉汽销前端业务。 ## 一、背景介绍近期在开发过程中因为 Git 操作不当以及使用不熟，带来了不少团队协作问题，比如：分支被覆盖、提交日志杂乱、分支创建很随意，同时在上线日当天需求被推迟上线，前端又需要对代码进行回滚以及 `rebase` 操作等系列问题。针对以上内部遇到的 Git 问题梳理了相关操作规范和 Git 使用指南。 ## 二、Git 介绍 Git 是一个分布式版本控制工具，它可以非常轻松帮你管理任何时间任何人做的任何提交。知识虽旧，历久弥坚。本文总结了在货拉拉日常工作中是如何玩弄 Git 的，希望这篇总结对部分 Git 操作不熟的同学有所帮助。 ### 概念理解使用 Git 之前先了解 Git 仓库运转流程，共分为4个概念：本地空间、暂存区、本地仓库和远程仓库。如下图： ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d5b451ba3c5e4544a757fa3613e2773f~tplv-k3u1fbpfcp-zoom-1.image) - 本地空间：存放的本地代码 - 暂存区：存放修改后的文件 - 本地仓库：存放提交修改后的文件 - 远程仓库：存放远程推送代码是不是有点像 `Vuex` ： `Action` -> `Mutation` -> `State` ## 三、Git 工作使用 ### 安装配置 - [下载 Git 软件](https://git-scm.com/downloads) - 全局配置邮箱和账号 ```shell git config --global user.name "zhangsan" git config --global user.email "zhangsan@github.com" ``` > 1. 配置账号和邮箱后，提交代码会显示提交人，便于问题追查和 CR 。 > 2. 想要托管账户，可使用`ssh-keygen -t rsa -C "xxx@github.com"`生成公钥，把`id_rsa.pub`内容复制到`SSH keys`。 ### 常用操作日常工作中，对于 Git 的掌握用好了，也是一种提效，以下总结一些日常必备的 Git 技能。 #### 远程仓库 1. 克隆远程仓库 ```shell git clone ``` 2. 关联远程仓库 ```shell git remote add origin ``` > 本地已存在的项目关联到已有的仓库中。 #### 代码提交 1. 代码拉取 ```shell git pull ``` 2. 文件暂存 ```shell git add . ``` > 注意后面是一个点，点代表暂存所有，单个文件暂存改成文件路径即可。 3. 本地仓库提交 ```shell git commit -m "feat: 开发订单" -a ``` > -m 代表提交备注，-a 代表提交所有文件。提交描述可参照下文的提交规范。 #### 代码合并如果想要把 `feature/order` 合并到 `release` ```shell # 切换到 release 分支 git checkout release # 合并功能分支到当前 release 分支 git merge feature/order ``` > 分支合并是基本操作，合并的过程中很多时候会产生冲突，如果不确定使用谁的代码，最好跟当事者沟通一下。 #### 远程推送 ```shell git push ``` > 如果推送的时候被驳回了，大概率是冲突了，优先解决冲突并从新推送；如果确认使用本地代码，则可以使用 `--force` 强制推送。 #### 分支操作 - 查看本地分支：git branch - 查看远程分支：git branch -r - 查看所有分支：git branch -a - 切换分支：git checkout - 切换并创建新分支：git checkout -b - 删除本地分支：git branch -d - 删除远程分支： git push origin : - 合并分支：git merge ### 代码回滚 1. 本地代码丢弃 ```shell # 单个文件丢弃 git checkout main.js # 所有文件丢弃 git checkout . ``` 2. 撤销某次提交 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/92e0d92ebc544a3b834f10d9252f2b20~tplv-k3u1fbpfcp-zoom-1.image) 如上图，可以看到有2条记录，如果想要撤回`log 1`的提交代码，可使用 `git revert ` 进行回滚。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f4d90cc15b0a43f9a3f5716cfb7f0e77~tplv-k3u1fbpfcp-zoom-1.image) ```shell git revert 0ac68bc3a99a351b4ef9e475436efffa307e7288 ``` > 使用 `git revert` 会生成一条新的提交记录 3. 软回滚 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a3095e9e3dbf43c39c10cf9ea5ac2818~tplv-k3u1fbpfcp-zoom-1.image) 同样以上图为例，如果发现`log 2`的提交只是部分代码写错了，我们想要撤回来从新修改一下再提交，并不是完全舍弃，可使用 `git reset --soft ` 进行软回滚。 ```shell git reset --soft ``` 需要注意的是，`commit` 指要回滚到哪个版本，此版本以后的提交都会被回滚（**不包含当前版本**），而 `revert` 只能撤销某一条提交。回滚以后，从新执行 `git status` 你会发现这 `log 2` 文件变成了 `modify` ，也就是跟刚做完未提交是一个状态，此时我们可以若无其事的正常开发，正常提交。但是推送的时候由于跟远程仓库不一致，我们需要执行`--force`进行强制推送。 4. 硬回滚 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ce71ff3b917e4709970d6a04e3e54e71~tplv-k3u1fbpfcp-zoom-1.image) 同样以上图为例，如果发现 `log 2` 完全提交错误，想要舍弃，此时可使用 `git reset --hard `进行回滚。 ```shell git reset --hard ``` ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3eeb5f91177840e083bbf3036dd7cfcb~tplv-k3u1fbpfcp-zoom-1.image) 执行完硬回滚一下，本地仓库会完全删除 `log 2`的代码，我们只需要强制推送即可。 > 软回滚本地会保留提交代码，硬回滚本地会删除对应提交代码。最后都必须通过`--force`才能推送到远程。为了方便起见，可使用 `[HEAD]`进行快捷操作，比如：`git reset --soft HEAD~3` 回退到前3次。 ## 四、规范多人协作时，为了更好管理分支以及提交日志，我们最好建立相关规范，提高协作效率。 ### 分支规范 | 分支 | 介绍 | 环境 | | :---------: | :--: | :-----------: | | master | 仓库默认分支，暂无使用 | - | | release | 线上保护分支 | Prd | | release-pre | 预发环境分支，用于QA做固定Pre测试 | Pre | | test | 测试环境分支，用于QA做固定Test测试 | Test | | feature/xxx | 功能开发分支 | Dev/Test | | hotfix/xxx | 热修复分支 | Pre/Prd | | release-2022xxx | 上线分支；上线当日部署到Pre进行验证，通过以后直接作为上线分支使用 | Pre/Prd | 日常开发中，对于线上环境、预发环境和测试环境建议使用固定分支进行部署，所有分支以 `release` 作为基线分支。之所以不用`release-pre` 或者 `release` 作为上线分支，是因为上线当天经常因为各种原因导致只有部分`feature`是可以上线的。上线当天创建 `release-20220818` 并部署到Pre，如果验证通过直接部署上线，如果部分上线，则直接丢弃，再创建一个新的上线分支即可，避免污染 `release` 。 ### 提交规范提交代码时，务必填写提交日志，日志清晰明了，说明本次提交的目的。同时需要遵循一定的提交规范。 ```shell (): ``` 1. Header：包括三个字段：type（必需）、scope（可选）和subject（必需）。 2. Type：提交commit的类别，建议使用下面标识 - feat: 加入新特性 - fix: 修复bug - improvement: 在现有特性上的改进 - docs: 更改文档 - style: 修改了代码的格式 - refactor: 代码重构,不包含bug的修复以及新增特性 - perf: 提升性能的改动 - test: 测试用例的改动 - build: 改变了构建系统或者增加了新的依赖 - ci: 修改了自动化流程的配置文件或者脚本 - chore: 除了源码目录以及测试用例的其他修改 - revert: 回退到之前的一个commit 3. Scope：用于说明 commit 影响的范围，默认可忽略。 4. Subject：简短精炼的提交描述。 ## 五、超实用技巧 ### 场景一如果我们正在开发一个功能，突然告知有线上问题，我们**做了一半的代码如何保存**？ ```shell # 缓存本地开发文件 git stash # 取出最后一条缓存记录并删除 git stash pop # 查看所有缓存列表 git stash list # 应用某一条缓存 git stash apply stash@{index} ``` 1. 使用 `git stash` 可以临时存储本地所有变动的文件，并从当前分支删除修改的代码。 2. 切换到 `release` 创建 `hotfix-xxx` 修复问题。 3. 切换到 `feature/xxx` ，执行 `git stash pop` 还原刚刚开发的代码。一切都像没发生一样，很丝滑。 ### 场景二 `release-pre` 合并了 5 次提交，最终`QA`反馈只有一个功能对应的2次提交可以上线，我们如何把其中 2 次提交代码合并到`release`? - 方法一：把需要上线的功能分支直接合并到 `release` 进行上线。 - 方法二：使用`git revert 回滚其中不必要的提交。 - 方法三：使用`git cherry-pick`挑选需要的提交进行合并。 ```shell # 把某一次提交应用到当前分支 git cherry-pick # 把某几次提交应用到当前分支 git cherry-pick

# 把某个区间的提交应用到当前分支，注意不包含起始提交 git cherry-pick .. ``` ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/852f39340d1640cdabe78dd72348449a~tplv-k3u1fbpfcp-zoom-1.image) 如上图，如果想要挑选 4 和 5 的提交代码到 `feature/order` 分支，则执行：`git cherry-pick 0c20eb75..6938e5e0` 即可，注意不包含起始提交，**左开右闭**。 ### 场景三某需求做完以后，提测的时候通过 `git log` 发现 `feature/order` 分支有无数的提交记录，如下图，如何在提测的时候，让**提交日志更干净**？ ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fca8ac3c48c64b97b2e6abfb13806b3f~tplv-k3u1fbpfcp-zoom-1.image) 通过`git rebase -i

` 1. 执行命令，弹出交互式界面 ```shell git rebase -i 6938e5e0 ``` ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/33bfab27e5f24a1b96894c2a92d57d9b~tplv-k3u1fbpfcp-zoom-1.image) 2. 修改指令 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3ee3cfed46e14278ae0c92ae5811d7e5~tplv-k3u1fbpfcp-zoom-1.image) 我们只需要把最后三次提交的`pick`指令改为`squash`或者`fixup`即可，更多参数可参考如下： > - pick：保留该commit（缩写:p） > - reword：保留该commit，但我需要修改该commit的注释（缩写:r） > - edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e） > - squash：将该commit和前一个commit合并（缩写:s） > - fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f） > - exec：执行shell命令（缩写:x） > - drop：我要丢弃该commit（缩写:d） 3. 输入 `:wq` 保存后，会进入到从新修改提交日志界面 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2605f2649c04483bb2c48e30e8198669~tplv-k3u1fbpfcp-zoom-1.image) 4. 我们只需要删除这些日志，从新输入我们本次功能开发的日志即可： ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b84a83dbdafa49e5b6ee9e2df2bc65de~tplv-k3u1fbpfcp-zoom-1.image) 5. 再次输入：`:wq` 保存退出即可，最后查看日志如下： ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c3496a45cdaf440c8255cfb6d5fcbc40~tplv-k3u1fbpfcp-zoom-1.image) 这个世界真的很美好！！！ ### 场景四多人协作时，分支提交错综复杂，如何让分支提交变的更加线性？ **现实是这样的？** ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/28c60fffdeb447908d9aee6bb75f5224~tplv-k3u1fbpfcp-zoom-1.image) **使用 `rebase` 变基前后对比** ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a25c274656d14c658b7fac4ba0423d27~tplv-k3u1fbpfcp-zoom-1.image) 已知线上分支 `release` 和功能分支 `feature/order` ，当功能分支开发的同时，`release` 也同步做了修改（hotfix合并进来），此时我们通过 `rebase` 进行**变基** ```shell # 切换到功能分支 git checkout feature/order # 执行变基 git rebase release ``` 相当于临时保存 `feature/order` 分支代码，从新拉取 `release` 最新代码到本地，然后把 `feature/order` 合并进来，这个过程称之为**变基**，如果中间发生冲突，我们需要正常处理冲突，处理完以后，使用 `git add .`添加到暂存区，使用`git rebase --continue`继续执行，直到所有冲突解决完为止。如果中途想要放弃，可使用 `git rebase --abort` 进行终止。 > `git merge` 是以提交的时间为先后顺序，而 `git rebase` 不同， `release` 代码提交在前，功能分支提交在后，哪怕功能分支先提交的也不行。以上就是给大家准备的Git指北，看完如果有问题可以在评论区留言，如果感觉有帮助，请点个赞，最后附上一张我收藏多年的宝藏图。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/29296776aa2c4d93a2c6357cc5a2ff59~tplv-k3u1fbpfcp-zoom-1.image)