Question

在工作中我们压缩特征分支而不是合并它们以保持release分支清除并与feature分支断开连接。

我们目前正在这样做：

git checkout release
git merge --squash feature
git commit -m 'Squashed Feature 123'

但是由于一些后端自动化系统要求，我们想知道功能中的哪些sha创建了壁球提交而没有合并和而没有修改功能分支

自动化的目标是告诉管理层feature已被压缩为release（无论冲突及其解决方案）。这样做的唯一一致方式是以某种方式＆＃34;注册＆＃34; feature HEAD进入壁球提交。如果开发人员将更多提交推送到feature，则自动化系统会将其标记为＆＃34; unsquashed＆＃34;再次，因为feature HEAD现在指向一个尚未被压扁的sha。

我找到了3种可以标记壁球提交的方法，以便自动化系统可以将feature识别为压缩到release，但没有一种令人满意：

压缩后的

1）git merge -Xours feature将创建一个额外的提交，用于向自动化系统指示合并到feature的{{1}} sha。但是现在我们有2个提交加上整个历史就像合并一样，所以不是解决方案，因为我们不想要release历史记录。

压缩后{p> 2）feature会使git replace --graft release release~1 feature成为feature的祖先。这也有效，但就像1），这将带来历史，我们想要避免，所以不是解决方案。

3）release字符串可以标记自动化系统，壁球提交实际上是来自某个提交的合并。这可能是一个解决方案....问题是正确地提交提交消息凌乱且容易出错。

有关如何以一种既可以自动解析的方式实现这一目标的任何见解，也足以让用户在其合并工作流程中实现这一点？

现在，我们不必使用git commit -m 'squashed from [SHA=$feature_squashed_sha]'，如果它以一致的方式将壁球指向其原始的sha，则欢迎任何其他不可合并的方法

此外，自动化系统可以配置为运行任何命令，只要它给出问题的答案 git merge --squash HEAD被压扁到feature？

Answer 1

怎么样......

git checkout release
git checkout -b feature-123-abcd1234
git merge --squash feature-123
git checkout release
git merge --no-ff feature -123-abcd1234

显然，这最终会再次合并，但它们可能是微不足道的，可以被允许吗？

另一个解决方案是将压缩的SHA存储在存储库本身的增长文本文件中。

最后，您可以在每次压缩时简单地标记要素分支......

Answer 2

您选择的工作流程似乎有些奇怪。假设您在feature上有三次提交想要压缩release - 为什么不这样做

git checkout feature
git rebase release
git rebase --interactive HEAD~3   # (squash the latest two commits into the third)
git checkout release
git merge release                 # (fast-forward merge to keep commit history clean)
git checkout -
...continue working on feature...

这样，您可以避免合并提交。上面对我来说似乎等同于你正在做的事情，除了简单的git log release..feature足以告诉你哪些提交还没有被压缩到release。

毕竟，git merge --squash的精神是将杀掉 feature，并将其整合到release中。你试图做的事情更接近于变革。

如果您已与git merge --squash工作流程结合，请创建lightweight tag并让开发人员在挤压合并之前运行git tag -a squashed。

（免责声明：我对git来说相对较新。）

如何知道一个分支是否被压扁到另一个分支

2 个答案: