Question

例如，我完成了一个功能分支，将其推入并合并到远程开发分支中。 3天后，我发现该分支上有错别字，那么修改该分支的最佳方法是什么。创建一个新分支来纠正这个琐碎的错误，还是在旧分支上进行重做？您能用git命令举例吗？谢谢！

Answer 1

如果我理解正确，那么您是在谈论一个政策问题，而不是真正的技术问题。技术部分是相同的-您会将其视为任何其他更改。要合并的另一个分支（如果这是您的工作流程）。

无论您是在 new分支上还是刚刚合并的 old分支上提交新的错别字，对于git来说，树都一样在两种情况下。

新提交，无修改，稍后合并

合并次要提交后的样子如下：

A-B-C-D-G-H-I-J (develop, newMergedBranch or oldMergedBranch)
 \   /       /
  E-F----Typo

重要的一个地方是合并提交本身。它会说Merged in branchName。因此，根据您希望的外观（如果未编辑合并提交），可以选择要使用的分支名称。

修改然后再次合并

澄清有关修改的影响，以回应评论：修改是否是错误的做法，取决于人们现在是否在D之外工作。如果某人在D之上进行了提交，然后又修改了一个较早的提交（例如，使用git rebase -i的F），则您将进行更改下游的一切。

注意：对于下面的所有D，C是父代。 D'是合并提交。

A-B-C-D--G-H-I-J (other develop)
 \   /       
  E-F  D' (your develop, oldBranch)
   \F'/ (Typo)

要解决此问题（在没有强制推送的情况下-使用强制更新，来自D的所有拉动都必须强制拉动，如果他们不知道，则可能会丢失更改。它们首先会遇到拉动冲突，即使它们是正确地做所有事情。这就是为什么对裸露的分支进行历史修改被认为是不好的做法），因此必须合并您的开发内容：

A-B-C-D--G-H-I-J-K (develop, old branch)
 \   /          / 
  E-F  D'-------
   \F'/ (Typo)

为澄清起见，此图中D'不在F的下游。

总结起来，这与旧方案完全一样，即不修改提交的方案。只是如果您修改提交，它看起来“更丑”。但是，强行推动是不好的做法。无论如何，您可能无权这样做。

如果您将其余的开发工作和基础推入基础，那么被拉的人将具有：

A-B-C-D-G-H-I-J-L1-L2-L3 (other person's local develop, L1- being local commits)
 \   /           
  E-F  
   \F'-D'-G'-H'-I'-J' (develop)

然后，当他们拉动新的，重新建立基础的开发人员时，他们将发生冲突，然后必须再次合并。或做一些更复杂的事情（如变基）来实现：

A-B--C
 \    \ 
  E-F'-D'-G'-H'-I'-J'-L1-L2-L3 (develop)

至关重要的是，他们将必须知道要这样做（其中一个人是他们），否则他们将合并并徒劳地进行所有工作-导致再次合并。 / p>

关于政策：

您已致力于该代码，现在没有更改。没有修改，没有历史覆盖。您将不得不忍受它。

如果要进行的更改很重要，那么您现在就已经完成了。如果不是，而是类似“宠物怒气”，它现在取决于您的提交策略是什么。您（组织，团队等作为集体决定）是否想要坐在那里的整个提交只是为了纠正错字？

大多数团队对此表示满意。没有人会受到伤害或烦恼以至于无法提出来。如果其他人可能会在代码库的那个区域上工作并且遇到该错字并感到烦恼，则一定要解决它-没有两种解决方法。

如果不是这样，而且大多数情况下都是孤立的，那么我在您所处的情况下所做的就是将所做的更改放在某个分支的某个位置上，也许放在您的藏匿处。接下来，当您再次需要使用该代码库时，您也可以向其中添加此错字更改。