Git 如何知道一根树枝是否被压成了另一根

在工作中，我们挤压特征分支，而不是合并它们，以保持

release

分支干净，并与

feature

分支断开连接

我们目前正在通过以下方式实现这一目标：

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

但是由于一些后端自动化系统的要求，我们想知道功能中的sha在不合并和不修改功能分支的情况下创建了挤压提交

自动化的目标是告诉管理层，

功能

已被压缩到

版本

（无论冲突及其解决方案如何）。唯一一致的方法是以某种方式将

特性

头sha“注册”到壁球提交中。如果开发人员将更多的提交推送到

功能

，自动化系统将再次将其标记为“未压缩”，因为

功能

头部现在指向尚未压缩的sha

我已经找到了3种方法来标记压缩提交，以便自动化系统能够将

功能

识别为压缩到

发布

，但没有一种方法是令人满意的：

1）

git merge-Xours功能

挤压后将创建一个额外的提交，用于向自动化系统指示已合并到

发布

中的

功能

sha。但是现在我们有2个提交加上整个历史记录，就像一个合并一样，因此不是一个解决方案，因为我们不需要

功能

历史记录

2）

git replace--graft release release~1功能

挤压后将使

feature

成为

release

的祖先。这同样有效，但就像1），这将再次带来历史，这是我们想要避免的，因此也不是一个解决方案

3）

git commit-m'squashed from[SHA=$feature\u squashed\u SHA]”

字符串可以标记自动化系统挤压提交实际上是某个提交的合并。这可能是一个解决方案。。。。问题在于，正确地获取提交消息是混乱的，并且容易出错

对于如何以一种既能实现自动化解析又能让用户轻松实现其合并工作流的方式实现这一点，您有何见解

现在，我们不必使用

git merge--squash

，任何其他不可合并的方法都是受欢迎的，如果它以一致的方式将squash指向其原始sha

此外，自动化系统可以配置为运行任何命令，只要它给出问题的答案，是否将

功能
头部挤压到
释放
？
如何

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存储在存储库本身中不断增长的文本文件中

最后，您可以在每次挤压功能分支时简单地标记它…
您选择的工作流似乎有点奇怪。假设您在
功能
上有三次提交，您想将其压缩到
发布
-为什么不这样做

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
的精神是在集成到
release
中时杀死
特性。你要做的是更接近于一个再基地

如果您与
git merge--squash
工作流结为夫妻，请在squash合并之前创建一个并让开发人员运行
git标记-a squashed

（免责声明：我对git比较陌生。）
您的替代移植（选项2）是可删除的，默认情况下不会从一个存储库复制到另一个存储库，因此我不确定反对意见是什么。通过提供一个运行
git merge--squash
的脚本，然后使用预先提供的消息执行
git commit
，和/或通过一个prepare commit msg钩子，可以自动化选项3。除了“真正的合并”以外的所有方法都是用户容易出错的。顺便说一句，我要提到的是使用不同的经验法则：一旦一个分支被挤压合并，它必须立即被删除。（如果有计划重新进行合并而不是推动合并，则原始所有者/合并可以将其重命名。）这可以防止错误地对其进行额外开发。删除功能分支非常有意义。唯一的问题是，如果没有功能分支，我们以后可能无法还原压缩的更改。@ojosilva您在此处关于无法还原压缩更改的评论，听起来好像您希望还原压缩合并之前进行的单个提交。如果是这样，那么它表明您确实关心在挤压之前所做的单个提交。挤压的本质破坏了提交历史的粒度。如果你关心那些presquash提交，我想问题真的变成了，我们为什么要首先做壁球？不，我们没有结婚的工作流。但是我们试图避免重定功能分支的基址，这有很多问题，比如功能混乱和不断丢失开发历史。但是我同意，挤压和删除分支可能是一种方法。
merge--no ff
在发行版中创建不必要的历史记录，类似于
merge-Xours
。我喜欢标签的想法，我没有想到！不过有点不稳定。@ojosilva:Merge no ff会创建额外的历史记录，是的，但保留历史记录是git的目的。DAG是git中唯一永久不变的东西，没有什么可怕的。也许你可以想一想，为什么你如此坚持没有任何“不必要的”历史。你是不是被它烧死了