前言
- 最近工作中发现，很多开发人员连最基本的Git怎么使用都不知道，比如什么时候切分支，什么时候合并代码，代码遇到冲突怎么办，经常出现掉代码，代码合并后丢失的情况。
- 以下为个人总结的常规Git开发工作流程的使用，每个公司使用不一致，仅供参考。
分支分类
- dev（开发）
- test（测试）
- uat （预发布）
- master （生产）
研发流程
- 需求评审
- 开发排期
- 编码开发
- 冒烟测试（单元测试）
- 冒烟通过，提交测试，合并代码到测试分支，部署测试环境
- 测试环境测试，开发修 BUG
- 测试完成，提交预发，合并代码到预发分支，部署预发环境
- 预发环境测试，开发修 bug
- 测试完成，产品验收
- 验收完成后，基于生产分支进行TAG
- 提交生产，合并代码到生产分支，部署生产环境
- 生产运营（客户）验收
- 验收完成，结项
实际操作
代码拉取
git clone https://code.xxx.com/xxx/xxx.git
- 查看本地分支：
git branch - 查看远程分支：
git branch -a
创建版本分支
- 本地创建版本分支：
git branch fix-20240223-order - 本地切换版本分支：
git checkout fix-20240223-order - 本地推送版本至远程仓库：
git push origin fix-20240223-order:fix-20240223-order
- 为啥拉取的是生产/预发分支
需求完成，提交代码
- 提交代码：
- 首先先在本地把新的改动提交，提交描述的格式可以参考着分支名的格式
- 提交本地代码至远程仓库
git add .
git commit -m "提交描述"
git push origin fix-20240223-order:fix-20240223-order
- 提交之前可能需要更新，因为该分支是一个版本分支，可能开发人员有几个人同时在这个版本分支进行开发，这个时候可能同一种业务就可能存在代码冲突，需要解决。
版本需求完成，合并代码
- 首先，我们需要认知到的是，每一个分支应该只对应一个版本，例如当我们开发01版本时，那么就创建一个 feat-01-order 分支进行开发；开发版本 02 时，就另外创建一个 feat-02-member 分支进行开发；修改生产环境的某个 bug 时，就创建 fix-bug-3378 进行开发，等等。
- 其次，在合并代码时，我们要将四种分支模型（dev、test、uat、master）作为参照物，而不是把关注点放在自己的分支上。比如我们要在 dev 上调试，那就需要把自己的分支合并到 dev 分支上；如果我们需要提测，则把自己的分支合并到 test 分支上，以此类推。
- 前面我们已经把本地的版本分支推送至远程仓库后，在本地进行分支合并至 dev或者test
- 把 本地版本分支 fix-20240223-order 更新至最新的代码，如合并至dev分支，更新dev分支至最新代码
- 切换至 dev 分支：
git checkout dev - 版本分支合并至dev分支(冲突解决)：
git merge fix-20240223-order - 环境分支推送至远程仓库：
git push origin dev
常见问题
预发环境修完的 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
写在最后
-
在团队内部使用规范的 Git 工作流程，可以帮助我们提高协作效率，减少混乱和冲突。比如规定好分支结构和命名规范，将使得代码库的分支结构更加清晰明了，更易于管理。反之，开发者可能会按照自己的喜好随意创建分支，导致代码库分支结构混乱。
-
除此之外还有很多好处，降低错误风险、增加代码可追溯性、简化发布流程、促进持续集成与持续交付等等。
-
参考资料：https://blog.csdn.net/u010800804/article/details/109594867