3

我在我的项目的一个分支上发现了一个崩溃问题。我修好了,承诺了。

然后我发现,与我最初的看法相反,那个特定的崩溃错误在多个分支中普遍存在,所以我在 master 分支中修复了它。

不幸的是,这让我在两个分支上进行了“相同”的提交(不完全相同,因为在同一代码区域中的分支略有不同)。

当我将更改从主服务器拉到分支时,有什么方法可以告诉 GIT 提交是相关的并且应该出于合并的目的而忽略?


作为背景,有问题的分支并非旨在添加功能,它旨在将有问题的应用程序“列入白名单”——相同的应用程序,具有不同的艺术作品和种子数据。(基本上,第二家公司授权我们的软件并假装它是他们的)。这是我能想到的最好的解决方案,让白标版本的软件基于主版本进行更新。

4

2 回答 2

3

如果您计划稍后合并或挑选樱桃,这应该不是问题。这样做的算法会注意到相似之处并做正确的事情。

如果合并这两个分支,您将有多个提交消息,但您应该 - 这是您合并工作的方式,这里的工作恰好具有相同的内容。如果你真的很担心,一旦你合并,你可以压扁,但我不会打扰,历史很重要。

于 2012-11-14T22:11:27.887 回答
2

我不确定您的 GIT 工作流程,但我会从 master 创建一个修补程序分支,修复该分支中的问题,并将其合并到所有相关分支中。

这样,如果/当您将分支合并到 master 中时,将不会有多个提交用于同一个修复。

于 2012-11-14T22:09:00.363 回答