这是通过 github 恢复还原更改的正确方法吗？

Question

在开发过程中，我将分支 a_feature 的 pr 合并到 develop 分支。然后我在我的电脑和 github.

中删除了 a_feature 分支

但是我把它弄错了，我想把它改回来。因此，我做了一个新的 Pr，通过 github 的内置功能恢复更改并将其合并回来。（我这样做是为了防止意外部署不需要的代码）

但我想继续将还原的更改开发到新分支中并进行新的 pr。那么我做的这个方法是正确的吗？

我拉develop支线：

git checkout develop
git pull origin develop

我做了一个新分支：

git checkout a_feature_with_nessesary_changes

我在还原之前查看包含更改的提交的日志：

git revert ^hash^

然后我提交更改：

git add .
git commit -am "Un-reverted changes"

一旦准备就绪，我会重新做一个新的 PR。

但是一旦我通过 github 恢复了一些合并更改，这是取消恢复的更改和大量丢失代码的方法吗？

Answer 1

这里有多种方法，但是关于 Git revert 最重要的是要恢复 PR 有点不同而不是恢复提交。当您还原常规提交时，您撤消了该特定提交的更改。当您还原 PR 时，您正在还原 merge 提交，并且该提交将撤消 all 中所有更改的总和 由该 PR 带来的提交。

这很重要，因为如果您选择继续在同一个分支上工作，那么当需要合并分支的 fixed-up 版本时，如果您希望 re-merge 提交任何内容仍然具有与之前合并中相同的 ID，这些提交将不会被第二次引入。它们必须是 re-written，所以我的偏好是始终从目标的最新版本开始（如您建议的那样），这将强制执行。这是一种创建该分支的更有效的方法，无需先检查 develop：

# make a new branch off of the latest develop
git fetch
git switch -c a_feature_with_nessesary_changes origin/develop --no-track

现在您可以还原还原提交：

git revert <commit-id-of-revert-commit>`

或者，您可以 cherry-pick 分支上的所有原始提交：

git cherry-pick <commit-id-a_feature-branched-from>..a_feature

请注意，cherry-pick 范围内的第一个提交是要选取的第一个提交的 parent。您需要的父提交很可能等于此命令的输出：

git merge-base origin/develop a_feature

在 merge-base 正确的情况下，您可以将 cherry-pick 更改为如下内容（使用 Bash）：

git cherry-pick $(git merge-base origin/develop a_feature)..a_feature

为了完整起见，如果您真的想重用 a_feature 上的原始提交而不是从最新的 develop 开始（有些人不喜欢更改原始合并基础），我会提到，那么您可以简单地强制重写分支以仅更改 ID：

git switch a_feature
git rebase -f $(git merge-base origin/develop a_feature) # -f forces the rewrite

无论您选择了上述哪个选项，现在您的分支都处于旧代码（仍然损坏）的状态，可以修复。此时，您可以像往常一样将您希望进行的更改和 PR 添加到 develop 中。

这是通过 github 恢复还原更改的正确方法吗？

Is this the proper way to restore reverted changes via github?

git

github

git-revert