情况是这样的。我有主人和一个分支，可以称之为“image2”
因此，从最新的 master 到最新，我分支并创建了 image2。我继续在 image2 分支上工作.. 一段时间后，发现一个巨大的错误也影响了 master。
现在因为主版本已经上线，我需要在那里修复它。我结帐到 master，修复其中一个文件中的错误（我们称之为文件 A），然后返回 image2 继续处理该分支。问题是，现在修复仅适用于 master，而不适用于 image2。 问题是：将主修复应用于 image2 的正确方法是什么？因为合并我估计会麻烦，因为image2中文件A的代码有很多新东西，但也需要master中应用的修复。
谢谢
【问题讨论】：
如果 image2 分支没有被推送到远程仓库，你可以在新的 master 上 rebase 这个分支。如果它已经被推送到远程仓库，你需要将它与新的 master 合并。
如果合并是一个大问题，您可以只应用修复主分支中的错误的提交。为此，请使用“cherry-pick”命令。
在 image2 分支上运行 git cherry-pick sha-value-of-the-commit
【讨论】：
您正在寻找一个名为 Git Flow 的 Git 分支策略
这为许多常见的开发场景定义了一个策略，包括您在问题中描述的“修补程序”场景。
master 应始终包含在生产中运行的代码。因此，当您需要修复产品中的错误时，您可以正确地说，您从master 创建了一个修补程序分支。修复bug后，将hotfix分支部署到prod，然后合并到master。
由于功能分支可能会过时，因此通常需要从 master 或 develop 刷新功能分支。如果您想 merge master/develop 进入您的功能分支，或者如果您想 rebase 您的功能分支在 master 之上，这是您的偏好。我个人的偏好是变基。
因为合并会出问题
如果您指的是合并冲突，那么是的，当您有并行开发轨道（即hotfix 和feature 分支）时，很可能会出现合并冲突。这个想法是尽早解决合并冲突，这样它们就不会堆积起来。如果您计划将功能分支变为主分支，则最终需要解决冲突，但功能分支有责任解决这些冲突并保持最新状态。
这是伟大的 gitflow 分支图供参考。这应该有助于说明应该如何以及何时合并分支：
【讨论】：