【问题标题】:x commits behind master, how to do without merge master on branchx 在 master 后面提交,如何在分支上不合并 master
【发布时间】:2021-05-07 14:27:00
【问题描述】:

我正在使用 git 来维护我的代码,现在我基本上有 3 个分支:

  • master(受保护,无法直接编辑)

  • 开发

  • releaseversion(可以是v1、v2等)

很久以前,我在 master 上进行了一次合并,我通过接口恢复了(仅在 master 分支上),但现在我的开发分支总是在 master 后面 10 次提交,但我不能将 master 合并到开发,因为它会导致代码回归。

如何在开发时重置这些提交?有没有办法“取消”这些在 master 上的提交?或者根据当前开发状态​​重置master的方法?

谢谢

【问题讨论】:

  • 我建议对发布版本使用标签,而不是分支。

标签: git merge commit master


【解决方案1】:

这里可能存在更大的问题(因为您有一个还原的合并,如果将来您想将这些提交的更改重新合并到master 中,这将成为阻碍)。

也就是说,在不影响develop 分支内容的情况下,让 git 不说你落后于 master最简单方法是使用 ours 合并策略进行合并( 不要与可以赋予默认合并策略的 ours 选项混淆)。

git checkout develop
git merge -s ours master

在纸面上,这告诉 git develop 并不是真的master 后面,master 只包含与 develop 永远不会相关的提交。

这样做的缺点是它“隐藏”了合并中的更改。一些命令(可能还有一些开发人员)假设如果合并提交的父级可以使用默认的合并策略在没有冲突的情况下合并,那么这就是发生的事情 - 所以像这样的合并,打破了这个假设有时被称为“邪恶合并”。

另一种选择是继续将master 正常合并到develop,然后恢复那个合并。

git checkout develop
git merge master
git revert -m1 HEAD

我知道这听起来让我提出的第一个问题变得更糟,但这是一种罕见的情况,即两个错误可能成为正确。这里的优势是(粗略地说)在将来的某些合并中,将develop 历史与master 再次结合起来,git 将看到develop 上的恢复(更改的重新声明)发生在之后 master 上的还原 - 所以合并的行为会像你期望的那样。而且你没有任何“邪恶”(或其他奇怪的)合并。

【讨论】:

  • 我唯一要补充的(如果这是你的意思)是将 master 合并到 develop 的想法是转身并立即将 develop 合并到 master。据我了解,反向合并只是为了推进 LCA。
  • @matt 不,没有理由立即重新掌握。整个问题是 OP 只是 revert 合并到 master ,因为他们不想要那里的更改(至少现在);你为什么会建议他们撤消呢?
  • 我认为目标 将 develop 合并到 master 中,但不再看到“后面的 10 次提交”。我可能会感到困惑。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2017-04-26
  • 1970-01-01
  • 1970-01-01
  • 2018-04-03
  • 2012-01-25
  • 2021-10-13
  • 2017-03-20
相关资源
最近更新 更多