使用git revert修复bug，还是基于有bug提交建分支合并更优？

首先纠正你对git revert的误解：它并不是“仅撤销有bug提交的影响，并未修复bug”——恰恰相反，git revert的核心作用就是精准撤销指定提交的所有变更，生成一个新的提交来抵消原提交的影响。如果你的bug完全是由master~5这次提交引入的，那么执行git revert master~5之后，bug就被修复了。另外，它也不会“带来文件缺失”：如果原提交删除了某个文件，git revert会自动恢复该文件；如果原提交是新增/修改内容，revert会对应删除/回改这些内容，都是预期的撤销行为。

接下来对比两种方案的适用场景：

方案1：切到master~5建分支修复后合并回master #

这种方式是基于旧提交的代码状态做修复，再把修复后的代码合并到当前master。它的适用场景是：

• bug不止由master~5单个提交导致，需要在旧代码基础上重新调整逻辑；
• 后续提交依赖了master~5中的部分变更，不能完全撤销该提交的所有内容。

但这个方案有明显缺点：如果master~5之后已经有多个正常提交，合并时很可能会出现大量冲突——因为你是在旧代码上改的，而master已经往前推进了，需要手动解决这些冲突，甚至可能不小心覆盖后续提交的正常变更。

方案2：直接在master上执行git revert master~5 #

这种方式的优势非常明显：

• 操作简单，无需切换分支、合并等额外步骤；
• 只会撤销master~5的变更，完全不影响后续的正常提交；
• 历史记录清晰，能明确看到“撤销了某次有bug的提交”这个操作，便于后续追溯。

它的适用场景是：

• bug完全由master~5这一次提交引入；
• 后续提交没有依赖master~5的变更，可以安全撤销该提交的所有内容。

总结 #

两种方案没有绝对的“更优”，要看具体场景：

• 如果是单个提交引入的独立bug，git revert是更高效、安全的选择；
• 如果bug涉及旧代码逻辑调整，或后续提交依赖原提交内容，才需要用回溯旧分支修复的方式。

内容的提问来源于stack exchange，提问作者alex_121