如何知道一个分支是否被挤压成另一个

Question

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

release

分支清洁并与

feature

分支断开连接。

我们目前正在这样做：

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

但是由于某些 后端自动化系统 要求，我们想知道功能中的 sha 创建了 squash commit without merging and without modifying the feature branch.

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

feature

已被压缩为

release

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

feature

HEAD sha“注册”到 squash 提交中。如果开发人员向

feature

推送更多提交，自动化系统将再次将其标记为“未压缩”，因为

feature

HEAD 现在指向一个尚未被压缩的 sha。

我发现了 3 种可以标记挤压提交的方法，以便自动化系统可以将

feature

识别为挤压成

release

，但没有一个是令人满意的：

1)

git merge -Xours feature

在 squash 之后将创建一个额外的提交，可以用来向自动化系统指示

feature

sha 被合并到

release

中。但是现在我们有 2 次提交加上整个历史就像合并一样，所以不是解决方案因为我们不想要

feature

历史。

2)

git replace --graft release release~1 feature

在南瓜之后将使

feature

成为

release

的祖先。这也有效，但就像 1) 一样，这将再次带来历史，这是我们想要避免的，所以也不是解决方案.

3)

git commit -m 'squashed from [SHA=$feature_squashed_sha]'

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

关于如何以一种既对自动化解析可靠又足够容易让用户实施到他们的合并工作流程中的方式来实现这一点有什么见解吗？

现在，我们不必使用

git merge --squash

，如果它以一致的方式使壁球指向其原始sha，则欢迎任何其他不可合并的方法。

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

feature

HEAD 被压缩成

release

？

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

工作流程，请创建一个 轻量级标签 并让开发人员在 squash-merging 之前运行

git tag -a squashed

。

（免责声明：我对 git 比较陌生。）

Answer 3

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

feature

已被压缩为

release

（无论冲突及其解决方案如何）。

这意味着您不能使用 git-cherry(1)，因为它在面对可能的冲突时无法检测 cherry-picks/squashes。

我认为torek是正确的；给定这些约束的唯一选择是将元数据添加到您的提交中，即第三个选项。

问题是正确获取提交消息是 混乱且容易出错.

然后你应该自动化元数据标记。

此脚本将让用户编写提交消息，然后添加两个 trailers 带有分支名称和该分支尖端的 SHA1：

#!/bin/sh

branch=$(git branch --show-current)
git checkout release
message=$(mktemp)
editor=$(git var GIT_EDITOR)
printf "\n\n# Write a message for your squash merge above\n" > $message
# FIXME Script should error out if the user doesn’t write anything
$editor $message
git merge --squash $branch
squashed_from_sha1=$(git rev-parse $branch)
final_message=$(mktemp)
git interpret-trailers \
    --trailer="Squashed-from-branch: $branch" \
    --trailer="Squashed-from-sha1: $squashed_from_sha1" \
    <$message > $final_message
git commit -F $final_message --cleanup=strip

例如：

commit 8aa50b19861c0d405c29bd3911e152df8e04689d (HEAD -> release)
Author: Victor Version Control <[email protected]>
Date:   Tue Apr 11 19:52:46 2023 +0200

    Feature X

    I spent two weeks implementing this (ugh) so I don’t want to write
    any more about it now…

    Squashed-from-branch: x
    Squashed-from-sha1: 7a6d81d37f5190405ba582a95d712add8392babc

获取/解析两个值：

git log -1 --format="%(trailers:key=squashed-from-branch,valueonly)" <sha1>
git log -1 --format="%(trailers:key=squashed-from-sha1,valueonly)" <sha1>

担忧

正如您在评论中指出的那样，这根本不是一个好方法。跟踪“squash merges”和 cherry-picks 是乏味的，你不会从 git(1) 中得到太多帮助（尤其是在 squash merges 方面）。

一个功能要求是跟踪被压扁的分支。但那是不朽的吗？因为像

new-dialogs

这样的分支名称是非常短暂的，您可能希望从现在起大约一年后将其重新用于另一个功能。应该处理吗？