持续集成 - 关于利用git合代码版本的疑问？

Question

关于利用git合代码版本的疑问？

我现在的情况是我现在的项目在git有三个分支（test，uat，production），test环境没问题合并到uat代码，uat代码在完成测试后合并到production分支进行上线部署。
我现在在test进行项目需求的开发，但是在开发过程中我遇到需要修改线上提出的bug，因此我在test分支上有多次提交（比如提交未开发完毕的需求代码，或者提交修改好的线上bug的代码，或者提交其他优先级不高的测试修改）

现在比如说我刚修改的bug优先级比较高，我需要把现在这个bug修复的代码和之前的部分优先级不高的代码发布到线上测试环境（不包括我本次增加的需求代码），这次线上测试环境不涉及当前增加的需求代码的打包，但是我之前都是在test分支上进行开发，导致我现在test分支中以及进行好几次代码更新，我该怎么样操作能够比较好的将上次uat上的代码和本次需要上线的代码进行合并测试呢？

或者像你们开发的流程是怎么样的？怎么操作自己的代码仓库？

Answer 1

我提供两个解决方案，一个是创建bugfix分支，一个是不创建分支，给你参考一下将高优先级的bug修复代码合并到uat分支，而不包括未完成的需求代码。以下是详细的步骤总结：

备注：挑选提交这个如果不会使用，我也给个步骤放最后给你参考

第一种创建分支以下是详细步骤：

1. 创建一个新的分支

从当前的test分支创建一个新的分支，比如bugfix，用于处理高优先级的bug修复。

git checkout -b bugfix

2. 挑选提交

使用git cherry-pick命令，将需要的提交（即高优先级bug修复的提交）从test分支挑选到bugfix分支。你可以通过git log查看提交历史，找到需要的提交哈希值。

git cherry-pick <commit-hash>

3. 合并到uat分支

切换到uat分支，并将bugfix分支合并到uat分支。

git checkout uat
git merge bugfix

4. 推送到远程仓库

将uat分支的更改推送到远程仓库。

git push origin uat

5. 测试和部署

在uat分支上进行测试，确保bug修复没有引入新的问题。如果测试通过，可以将uat分支合并到production分支进行上线部署。

git checkout production
git merge uat

6. 推送到远程仓库

将production分支的更改推送到远程仓库。

git push origin production

通过这些步骤，你可以在不影响未完成需求的情况下，将高优先级的bug修复代码快速部署到生产环境。

第二种不创建分支以下是详细步骤：

使用git stash和git cherry-pick来处理高优先级的bug修复

1. 暂存当前更改

在test分支上，将当前未完成的更改暂存起来。

git stash

2. 挑选提交

使用git cherry-pick命令，将需要的提交（即高优先级bug修复的提交）从test分支挑选到uat分支。你可以通过git log查看提交历史，找到需要的提交哈希值。

git checkout uat
git cherry-pick <commit-hash>

3. 推送到远程仓库

将uat分支的更改推送到远程仓库。

git push origin uat

4. 测试和部署

在uat分支上进行测试，确保bug修复没有引入新的问题。如果测试通过，可以将uat分支合并到production分支进行上线部署。

git checkout production
git merge uat

5. 推送到远程仓库

将production分支的更改推送到远程仓库。

git push origin production

6. 恢复暂存的更改

回到test分支，并恢复之前暂存的更改。

git checkout test
git stash pop

通过这种方式，可以在不创建新分支的情况下，将高优先级的bug修复代码合并到uat和production分支，同时保留你在test分支上的未完成更改。

使用git cherry-pick从test分支挑选提交并将其应用到uat分支：

1. 查看提交历史

首先，你需要查看test分支的提交历史，以找到你需要挑选的提交。你可以使用以下命令查看提交日志：

git log --oneline

2. 记下需要的提交哈希值

找到你需要挑选的提交，并记下它们的哈希值。例如：

a1b2c3d 修复高优先级的bug
e4f5g6h 添加新功能（不需要挑选）
i7j8k9l 另一个bug修复

3. 切换到目标分支

切换到你想要将提交应用到的分支，比如uat分支：

git checkout uat

4. 使用git cherry-pick挑选提交

使用git cherry-pick命令，将需要的提交从test分支挑选到uat分支。你可以一次挑选一个提交，也可以一次挑选多个提交。以下是挑选单个提交的命令：

git cherry-pick a1b2c3d

如果你有多个提交需要挑选，可以依次执行git cherry-pick命令，或者一次性挑选多个提交：

git cherry-pick a1b2c3d i7j8k9l

5. 解决冲突（如果有）

在挑选提交的过程中，如果遇到冲突，Git会提示你解决冲突。你需要手动编辑冲突的文件，解决冲突后，使用以下命令标记冲突已解决并继续挑选：

git add <冲突文件>
git cherry-pick --continue

6. 推送到远程仓库

挑选提交完成后，将uat分支的更改推送到远程仓库：

git push origin uat

Answer 2

你的问题有点乱，简单读了读，大概了解到
1.你有三个分支test、uat、production
2.他们是逐步递进的test-->uat-->production,也就是说production是基线.
3.你可能需要修复线上bug，也就是hotfix

你其他的我没看明白，我给你几个我这么多年开发带团队或者说我分支管理的经验。
你要搞清楚几个概念:

1. 基线。在你这里, production就是基线，该分支代码代表了当前唯一的稳定版，所有代码都必须以它为基础开发。

2. test和uat分支必须从基线分支派生，且定期回溯。

   你的这个例子中，三个环境，三个分支，永远是 test--> uat--> production,大家每次开发都是从 test为基础开发，长此以往导致的问题就是， test、 uat、 production三个分支差异越来越大,合并越来越困难。
   相信你曾经听说过，MIUI的测试版比稳定版还要稳定，大概率就是这个原因。

3. 一切修改必须从基线派生。

如果是新功能，开发流程应该是这样的：

1. 新功能团队协定一个开发分支，从production派生,记为feat-A
2. 大家都从feat-A二次派生自己的子分支开发

3. 需要合并时，从自己的子分支合并到feat-A,并从production拉取最新，在test环境上进入提测流程

   如果有开发环境，此处应该 合并到feat-A,并从production拉取最新,在dev环境上自测, 后再进入提测流程

   有可能多个团队同时开发且共用环境，这时验证，应该仅部署自己分支验证，避免别人的影响，也避免带给别人影响,像阿里，腾讯的devops都是流水线的方式，从基线集成运行的。

4. 如有bug,从feat-A派生bug-A分支修复

5. 修复完成后，将bug-A合并到feat-A再次在test环境上验证,仍有Bug,重复4-5

   整个开发生命周期中，每人有一个自己的 feat分支，一旦该分支合并，应当作废，每次从祖先分支( feat-A)拉取新分支

6. 上线前，从production拉取最新的变更，解决冲突后，记为uat-A分支
7. 在uat环境上使用分支uat-A预发布验证
8. 如有bug,从uat-A派发分支uat/bug-A,修复
9. 修复完成后，将uat/bug-A合并到uat-A再次在uat环境上验证,仍有Bug,重复88-9
10. 验证完成，将uat-A合并到production,上线

如果是线上bug修复，开发流程应该是这样的：

1. 发现bug,定位到原因，准备修复，新建分支hotfix-A

2. 修复bug,在uat环境上仅部署hotfix-A分支验证

   UAT环境若无法复现该问题，应该使用灰度，或者绿环境
   仅部署 hotfix-A是为了排除别的分支带来的干扰，同时不能携带多余的分支上线

3. 验证当前问题，不通过重复2
4. 验证通过,将hotfix-A合并到production上线

几个解释：
1.一个功能开发完，这个feat分支就作废了
2.这个流程走下来，发现实际上test和uat分支根本不存在，实际也不应该存在
3.如果环境是共用的，test和uat分支隐式是存在,但不能作为基线，每个功能一上线，这俩分支必须重置为production,一切以基线为准。
4.上述的分支名都是随意起的，完全可以按照你自己的开发规范。

如果你按照上述流程，不管是merge还是rebase方式，都是非常顺畅的，最终的扯皮阶段，只有将uat-A合并到production上时才有。

Answer 3

### 回答

在你的情况下，你可以采取以下步骤来将紧急修复的 bug 合并到 UAT 分支进行测试，而不包括未完成的需求代码：

1. **创建一个新的分支用于发布**：
   从你当前的 `test` 分支上创建一个新的分支，这个分支将只包含你需要发布到 UAT 的代码。

git checkout test
git checkout -b hotfix-for-uat

2. **回滚或移除不需要的提交**：
在这个新分支上，你需要确保不包含未完成的需求代码。如果可以通过回滚（revert）或手动移除这些提交来清理历史，那就这样做。

例如，如果你知道哪些提交是不需要的，你可以使用 `git revert` 或者手动编辑文件来移除这些更改。

3. **合并到 UAT 分支**：
一旦你的 `hotfix-for-uat` 分支准备好，你可以将其合并到 `uat` 分支。

git checkout uat
git merge hotfix-for-uat

4. **测试和验证**：
在 UAT 环境中测试这些更改，确保 bug 被修复且没有其他问题。

5. **清理**：
在确认 `uat` 分支没有问题后，你可以选择删除 `hotfix-for-uat` 分支，或者保留它以备将来参考。

git branch -d hotfix-for-uat

6. **回到 `test` 分支继续开发**：
回到你的 `test` 分支，继续你的需求开发和其他工作。

git checkout test

### 开发流程建议

- **使用特性分支**：对于每个新功能或 bug 修复，都从主分支（如 `test` 或 `develop`）创建一个新的特性分支。这有助于保持主分支的干净和稳定。
- **持续集成和持续部署**：使用 CI/CD 工具自动构建和测试你的代码，这可以帮助你更早地发现和解决问题。
- **定期合并**：定期将你的特性分支合并回主分支，以避免合并冲突和长期未解决的依赖问题。
- **代码审查**：在合并代码之前进行代码审查，这可以确保代码质量并促进团队之间的知识共享。

通过这些步骤和流程建议，你可以更有效地管理你的 Git 分支和代码版本。