这是一个有关我在使用git时发现的特殊情况的问题。
说我有一个具有master分支的应用程序（当然有几次提交）。该应用程序正在运行。
然后我决定翻译（例如，实际的事情并不那么重要）代码中的注释，因此我创建了一个名为 translation 的分支，然后开始翻译所有内容。我犯了几次。
然后我意识到存在一个错误（与翻译无关的不相关）。我当然可以修复该错误，但是使用git 进行的正确方法是什么？
（考虑到此修补程序必须同时适用于主版本和翻译版本，但是主版本不必翻译任何内容（因此我想不合并吗？）
我可以想到两种可能性：
1）进入master，创建一个fix分支，修复bug并提交。然后去翻译，然后...。糟糕...我也不知道该如何“复制”该问题
2）翻译和合并中正确吗？ （但话又说回来，我不能合并翻译部分？）
答案 0 :(得分：1)
1）是修补程序策略。您将补丁提交到主服务器中，然后在需要/需要的地方选择该提交。
2）显然不是面向git的，并且容易出错
现有3）替代方法。您可以将修复程序注入翻译的历史记录中。怎么样 ？您的翻译基于大师，对吗？因此您可以在master上提交，然后将翻译分支重新建立在master之上。就像分支翻译时已经包含此修复程序一样。缺点：这将重写翻译的历史记录，因此，如果翻译是本地分支，则更好。如果不是，您将不得不强行推分支，这远非理想（如果您不确切知道自己在做什么）。 EDIT 缺点2：除此之外，3）意味着可能包括您在修订之前在master分支历史记录中插入的其他提交（在翻译分支中可能是不需要的）。
答案 1 :(得分：0)
我建议您的第一个建议，即回到master并在那里修复错误。假定该错误与注释的翻译无关，而可能与注释的翻译无关。
然后，您可以rebase在master上进行翻译分支，以引入错误修复，然后再准备将此功能分支合并回master。您可能会遇到很多合并冲突，因为所有翻译都发生了变化。但是，在那种情况下，即使您完全忽略该错误修复，也可能会遇到相同的冲突。
答案 2 :(得分：0)
最好的方法就像1）
开始掌握，创建一个修正分支，修正错误并提交。然后将其合并为master，然后将master合并为 translation 分支
如果只需要 translation 分支的修补程序，则可以cherry-pick将提交提交到分支。
答案 3 :(得分：0)
尝试此方法：
查看引入了该错误的提交，但是很久以前
git checkout -b fixthatbug $thatcommit