git - 如何 merge 一个只导致一次提交的 git 分支(比如使用 --squash),但允许 future 的 merge 而不会发生冲突?

标签 git git-merge git-commit git-merge-conflict

我有一个分支,自创建以来其中有很多提交,我想进行一次 merge 提交以将其移回主分支,使用一次提交。所以我知道的唯一解决方案是使用 git merge --squash branchname。这很好用,但如果有人向 branchname 添加更多提交,并且我再次将其 merge 到 master 中,我会从 branchname 上的初始新提交中得到冲突。如何防止 merge 冲突,同时仍然只在 master 中为每次 merge 保留一次提交?我研究过使用 git merge --no-ff 但它仍然将所有提交从 branchname 移动到 master

最佳答案

echo $(git rev-parse $result $result^ $merged) > .git/info/grafts
git merge topic

其中 $result 是由压缩 merge 产生的提交,$merged 是您 merge 的提交(即给定 git checkout master; git merge topic $result为 merge 后的master$merged为 merge 后的topic) .

info/grafts 文件包含临时的、repo-local 祖先覆盖。上面的 echo 记录,仅在此 repo 中,挤压 merge 的结果也将挤压 merge 提交作为其父项——即它记录了准确的 merge 历史。仅当两个分支的后续 merge 仍以相同方式看到 merge 更改时,未记录的 merge 才有效。

不要忘记 rebase 和 filter-branch 也会看到嫁接的祖先,如果他们重写 $result 提交,他们会在新提交中记录该祖先。


merge 功能分支当然很常见,只是不记录就做这件事并不常见,因为这使得 git(或任何 vcs)不可能总能找到正确的 merge 基础。许多未记录的 merge 在历史记录中根本没有留下正确的 merge 基础,您必须创建一个才能在以后获得良好的 merge 。只要在进一步的修改掩盖匹配的更改 block 之前通过记录的 merge 来支付技术债务,Cherry-picks 和 squash merge 就很棒。

如果您要 merge 的历史很丑陋,您会喜欢交互式 rebase 。它可以让您创建提交历史记录,如果您首先有远见地这样做的话。为发布清理更改是许多项目工作流程的基本组成部分。

关于git - 如何 merge 一个只导致一次提交的 git 分支(比如使用 --squash),但允许 future 的 merge 而不会发生冲突?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30426867/

相关文章:

git - 使用 gitlab api 更新并提交文件

file - 将 gitlab 提交消息保存到文件

Git,提交时阅读最新的提交消息

Git 推送错误

Xcode 不会 promise GIT

git - Docker + SSH + Git 克隆问题

Git:错误的 merge 冲突?

Git merge 与在本地和源上添加的 500 个文件发生冲突

linux - GIT:无法推送(奇怪的配置问题)

git merge --no-commit 与 git cherry-pick --no-commit