试图在 GIT 中找到“stomp”合并

Posted 2023-02-19

【中文标题】试图在 GIT 中找到“stomp”合并

【英文标题】：Trying to find a "stomp" merge in GIT

【发布时间】：2019-09-01 11:48:35

【问题描述】：

抽象场景：有master和一个分支。分支是后代是主人。与此处未显示的其他文件一起，它们都包含一个名为 subdir 的子目录，其中包含一系列 json 文件：

branch:
/subdir/1.json
/subdir/2.json

master:
/subdir/2.json
/subdir/3.json

我想做的只是将子目录从 master 合并到分支，其中分支子目录中的所有文件都被删除并替换为 master 的内容，而不会丢失分支中提交的历史记录，也不会影响任何其他文件在分支中。

所以合并后，branch的subdir和master的subdir看起来一模一样。

【参考方案1】：

没有合并参数可以做到这一点。

有一种方法可以在单个合并中做到这一点，但这可能是个坏主意。这种合并被称为邪恶合并，至少在某些人看来（参见Evil merges in git? 了解“邪恶合并”到底是什么）。一种“不邪恶”的方法是进行合并，提交结果，然后进行后续提交以使事情正确。另一种“不邪恶”的做法是进行提交以使合并正确，然后进行合并。无论哪种方式，您都有 两个 提交，其中一个是非邪恶的普通日常合并。

但是，如果您确实想将其作为单个合并进行，devil-may-care 至于它是否是邪恶的，您可以这样做：

$ git checkout branch
$ git merge --no-commit -s ours master
... Git does the merge, but stops before committing ...

$ git rm -r -- subdir           # needed only if there are files to remove

$ git checkout master -- subdir
$ git status                    # use git status often!
... you'll see some status ...
$ git diff --cached HEAD        # optional: see what's changing vs tip of branch "branch"
... you'll see some status ...
$ git diff --cached --name-status HEAD  # optional: see what files differ
... you'll see some status ...
$ git status                    # it's never wrong to use git status too often
... you'll see some status ...
... ok, we're really ready ...
$ git commit
<and write a good merge message>

请注意，在进行此合并后，Git 现在认为合并您刚刚合并的两个提交的正确结果就是您刚刚提交的任何内容。这会影响未来合并操作！

注意git rm -r 步骤（我一开始忘记了）：如果当前 (tip-of-branch) 提交中有文件 不是 在master 提示提交，应该在合并中删除。如果没有这样的文件，git rm -r 没有害处，但没有任何用处：我们将用后续的git checkout master -- subdir 步骤替换所有文件。

【讨论】：

谢谢，我已经尝试过单个合并，到目前为止它正在工作。

我不完全理解的一件事是对“git merge --no-commit -s ours master”的调用。这会将 master 合并到分支，但我担心它可能会将不需要的文件从 master 写入分支。如果它实际上没有这样做，那么它实际上在做什么，即为什么需要它？

git merge --no-commit -s ours master 的重点是进行设置，以便 next 提交将成为合并提交。 -s ours 使 Git 不采取实际的合并操作。我们即将通过git checkout master -- subdir 步骤完全替换索引和工作树的某些部分，所以如果Git 除了标记next 提交什么也不做也没关系被制作为“将是一个合并”。理解这一切的真正关键是 Git 从 index 中的内容进行新的提交。您的工作树存在只是为了让您可以工作。 Git 关心的是索引。