【Git工具实战】实用真实 Git 开发工作流程

前言

• 最近工作中发现，很多开发人员连最基本的Git怎么使用都不知道，比如什么时候切分支，什么时候合并代码，代码遇到冲突怎么办，经常出现掉代码，代码合并后丢失的情况。
• 以下为个人总结的常规Git开发工作流程的使用，每个公司使用不一致，仅供参考。
  

分支分类

• dev（开发）
• test（测试）
• uat （预发布）
• master （生产）
  

研发流程

1. 需求评审
2. 开发排期
3. 编码开发
4. 冒烟测试（单元测试）
5. 冒烟通过，提交测试，合并代码到测试分支，部署测试环境
6. 测试环境测试，开发修 BUG
7. 测试完成，提交预发，合并代码到预发分支，部署预发环境
8. 预发环境测试，开发修 bug
9. 测试完成，产品验收
10. 验收完成后，基于生产分支进行TAG
11. 提交生产，合并代码到生产分支，部署生产环境
12. 生产运营（客户）验收
13. 验收完成，结项

实际操作

代码拉取

git clone https://code.xxx.com/xxx/xxx.git
1

• 查看本地分支：git branch
• 查看远程分支：git branch -a

创建版本分支

• 本地创建版本分支：git branch fix-20240223-order
• 本地切换版本分支：git checkout fix-20240223-order
• 本地推送版本至远程仓库：git push origin fix-20240223-order:fix-20240223-order

分支名称是有规范和含义的，不能乱取
推荐格式：分支责任-需求日期/需求号-业务类型，一般按部门规范来，常见的有以下几种：

• feat：新功能
• fix：修补bug
• doc：文档
• refactor：重构（即不是新增功能，也不是修改bug的代码变动）
• test：测试
• chore：构建过程或辅助工具的变动

• 为啥拉取的是生产/预发分支

之所以要拉取 master 分支而不是拉取 dev/test，是因为后者可能包含着一些其他成员还未上线或者可能有 BUG的需求代码，这些代码没有通过验证，如果被你给拉取了，然后又基于此进行新的需求开发，那当你需求开发完成，而其他成员的需求还没上线，你将会把这些未验证的代码一起发送到 uat/master上，导致一系列问题。

需求完成，提交代码

• 提交代码：
• 首先先在本地把新的改动提交，提交描述的格式可以参考着分支名的格式

如果是新需求的提交，可以写成 “feat: 需求20240111-新增导出”
如果是 bug 修复，可以写成 “fix: 禅道3387-重复请求处理”

• 提交本地代码至远程仓库

git add .
git commit -m "提交描述"
git push origin fix-20240223-order:fix-20240223-order
1
2
3

• 提交之前可能需要更新，因为该分支是一个版本分支，可能开发人员有几个人同时在这个版本分支进行开发，这个时候可能同一种业务就可能存在代码冲突，需要解决。

版本需求完成，合并代码

• 首先，我们需要认知到的是，每一个分支应该只对应一个版本，例如当我们开发01版本时，那么就创建一个 feat-01-order 分支进行开发；开发版本 02 时，就另外创建一个 feat-02-member 分支进行开发；修改生产环境的某个 bug 时，就创建 fix-bug-3378 进行开发，等等。

这样做的目的是，能够把不同的功能/需求/修改分离开来。想象一下这样一个场景，如果有某些紧急的需求是需要提前上线的，而此时你的分支里既包含了这些紧急的需求，又包含了其他未开发好的需求，那么这两种需求就不能拆开来分别进行提测和上线了。

• 其次，在合并代码时，我们要将四种分支模型（dev、test、uat、master）作为参照物，而不是把关注点放在自己的分支上。比如我们要在 dev 上调试，那就需要把自己的分支合并到 dev 分支上；如果我们需要提测，则把自己的分支合并到 test 分支上，以此类推。

我们要关注到，这四个环境的分支上，会有什么内容，会新增什么内容。「切记不能反过来将除了 master 之外的三个分支合并到自己的代码上！！」 如果其他成员将自己的代码也提交到 dev 分支上，但是这个代码是没有通过验证的，此时你将 dev 往自己的分支上合，那之后的提测、上预发、生产则很大概率会出问题。「所以一定要保持自己的分支是干净的！」 而 master 分支对应的是生产环境，一般是最新的稳定版本，所以合并到自己的分支以获取最新的更改也是没什么问题的。

• 前面我们已经把本地的版本分支推送至远程仓库后，在本地进行分支合并至 dev或者test
• 把 本地版本分支 fix-20240223-order 更新至最新的代码，如合并至dev分支，更新dev分支至最新代码
• 切换至 dev 分支：git checkout dev
• 版本分支合并至dev分支(冲突解决)：git merge fix-20240223-order
• 环境分支推送至远程仓库：git push origin dev

常见问题

预发环境修完的 bug 要重新走测试再走预发，为什么呢？

预发布环境是介于测试和生产环境之间的一个环境，它的目的是模拟生产环境并进行更真实的测试。它是一个重要的测试环境，需要保持稳定和可靠。通过对修复的BUG再次提交到测试环境测试，可以确保预发布环境中的软件版本是经过验证的，并且没有明显的问题。

当然，也不是非要这么做不可，紧急情况下，也可以选择直接发到预生产重新测试

代码合并错误，并且已经推送到远程分支，如何解决？

• 假设是在本地合并，本来要把特性分支合并到 uat 分支，结果不小心合到了 master分支
• 切换到特性分支合并到的错误分支，比如是 master：git checkout master
• 查看最近的合并信息（按 q 退出查看）：git log --merges
• 撤销合并：git revert -m 1 <merge commit ID>
  【这里的 merge commit ID 就是上一步查询出来的 ID 或者 ID 的前几个字符】
• 撤销远程仓库的推送：git push -f origin master
  【这个命令会强制推送本地撤销合并后的 release 分支到远程仓库，覆盖掉远程仓库上的内容。（即，得通过一个新的提交来“撤销”上一次的提交，本质上是覆盖）】

cherry-pick 指令

• 作用：选择某些提交的变更并将其应用到当前分支
• 与 merge 的区别：如果你需要另一个分支的所有代码变动。那么就采用 merge；如果你只需要部分代码变动（某几个提交），那么就采用 cherry-pick

场景：有时候分支不一定是完全按照需求号来开发的，可能按照周期来进行开发，那当前版本内的分支上，可能就会包含着很多需求的提交，这时候，如果产品要求你只上某一个需求，但是其他的暂时还不能上，那就需要使用到 cherry pick 的操作，将该需求囊括的所有提交应用到对应环境分支上。「一定要注意梳理清楚被拆分需求是由多少 commit 组成的，不要有遗漏和多选。」
【更多参考：https://www.ruanyifeng.com/blog/2020/04/git-cherry-pick.html】

写在最后

• 在团队内部使用规范的 Git 工作流程，可以帮助我们提高协作效率，减少混乱和冲突。比如规定好分支结构和命名规范，将使得代码库的分支结构更加清晰明了，更易于管理。反之，开发者可能会按照自己的喜好随意创建分支，导致代码库分支结构混乱。

• 除此之外还有很多好处，降低错误风险、增加代码可追溯性、简化发布流程、促进持续集成与持续交付等等。

• 参考资料：https://blog.csdn.net/u010800804/article/details/109594867