git 认为分支缺失的提交已提前合并

Question

我的团队最近过渡到 GitHub Actions CI/CD 工作流程，我们遇到了一个我不确定如何最好解决的问题。

首先，我将描述我们当前的分支策略：

我们是一家使用组织开发模型的 Salesforce 堆栈商店。这意味着每个开发人员都有自己的沙箱，此外我们还有集成、UAT 和生产环境。

我们在 git 中创建了 3 个长期存在的分支，旨在代表每个非开发人员沙箱（

int

、

uat

、

main

）。预期的工作流程如下：

• 所有

  feature

  分支都应基于

  main

  。
• 一旦认为

  feature

  分支已准备好进行 QA，就会打开拉取请求以将该分支与

  int

  进行比较。压缩并合并后，GitHub Action 会将增量部署到集成环境。
• QA 完成后，将创建拉取请求以将

  feature

  分支与

  uat

  进行比较。压缩并合并后，GitHub Action 会将增量部署到 UAT 环境。
• UAT 签核后，将创建拉取请求以将

  feature

  分支与

  main

  进行比较。压缩并合并后，GitHub Action 会将增量部署到生产环境。
• 如果在任何时候

  main

  需要更新，

  feature

  分支应该是

  rebased

  位于

  main

  之上。

我们遇到的问题是，在

feature

分支合并到

int

和

main

后，我们的

int

分支似乎仍然认为它位于

main

分支后面。示例：

• feature/A

  和

  commit1

  已通过 Pull 请求压缩并合并为

  int

  、

  uat

  和

  main

  ，随后部署到相关环境中。
然后基于
• feature/B

   创建 

  main

  ，其中包括

  feature/A

  的更改。

• feature/B

  已准备好合并到

  int

  ，并且已创建拉取请求。
• 此时，git 没有看到

  commit1

  已在

  int

  中表示，并希望将此提交重新合并到

  int

  中。

查看它，我可以看到

commit1

在

int

分支中的哈希值与

main

中的哈希值不同。所以，我相信我理解为什么 git 不将这些视为相同的提交，但我不确定是什么导致哈希发生变化。

我确信我在这里忽略了一些东西，或者可能误解了 git 在幕后发生的事情。任何帮助将不胜感激。

Answer 1

一旦被压扁...

别再这样做了。

就像添加注释作为除臭剂来掩盖臭代码是一个坏主意一样，因为版本历史臭味而压缩分支也是一个坏主意（这始终是人们想要在拉取请求上压缩分支背后的原因） ，尽管表达为委婉语，如“清理分支”或其他什么）。

在交互式 rebase 中使用

fixup

或

squash

同时处理某个功能不仅完全没问题（我绝不主张提交是不可变的并且永远不应该更改），但更重要的是 - 几乎必需的。然而，在创建拉取请求时，历史记录应该是干净且正确的（包括所有提交都通过测试）并且压缩是错误的。

挤压会破坏你用

git bisect

深入分析问题的能力。正如您所经历的那样，它也会破坏您的工作流程。