又一个 Git 移动提交问题。
我有一个主分支，所有工作都在致力于。 客户决定功能123不再需要在发布（稍后发布）中。我需要将提交 B（因为我缺乏对 Git 工作流程的完整理解，因此有这个问题）拉到另一个批次中，以便我稍后可以合并它。
就像我可以回到过去知道这些提交需要在自己的分支上并执行此操作一样，这样我就可以在需要该功能时轻松进行合并。
A --> B --> C --> D (master)
想做：
A --> __ --> C --> D (master)
B (Feature 123)
所以我可以稍后执行此操作：
A --> __ --> C --> D --> FUTURE COMMITS --> Z (master)
/
B -----------------------[Merge] (Feature 123)
我想采用提交 B 并将其移动到主，以便稍后可以将其合并到主节点中。
我知道我需要在该提交进行分支，但如果主人仍然知道这些更改，我对我没有好处。 我知道我在想这个错误，所以任何煽动都是值得赞赏的。
此外，这些提交已被推送到源头，并已被其他开发人员拉下。
您可以在 B 创建一个新的功能分支，然后在 A 之上重新设置主分支的基数：
git branch feature123 B
git rebase --onto feature123^ feature123 master
这将重写主分支的历史记录。 它将在A之上重播C和D，这可能会引起已经拉出这些提交的人的混淆。
一种与您在图中说明的内容不完全匹配但避免要求master分支历史记录的替代方法是恢复提交B：
git revert B
这将在主分支上记录一个新的提交，以恢复B中引入的更改。 稍后可以使用 git cherry-pick B 重新应用该提交。