如何将长时间运行的git分支重置为master？

我们有一个

master

分支机构和许多短期功能分支机构，这些分支机构在客户接受更改后被合并到

master

除此之外，我们还为用户验收系统和生产系统设立了长期生活环境分支，名为

stage

和

prod

，它们最初是从master分支出来的

我们的工作流程如下所示：

• 在功能分支上开发功能
• 将功能分支合并到

  阶段

• 等待客户接受
• 验收时合并到主控

• master

  第二天被合并到

  prod

客户接受可能需要很短时间，也可能需要很长时间，因此

stage

上有几个“功能”正在等待接受或放弃。因为如果客户不接受更改，我们不会将该功能合并到

master

，但遗憾的是，它像僵尸一样存在于

stage

）

现在问题是：

我们如何将分支

阶段

重置为当前

主

，而不丧失将仍在等待接受的功能分支再次合并到

阶段

的能力？这里的目标是摆脱被抛弃的“特征”

---

这在不改变历史和强制推送的情况下是可能的吗？

如果不重写历史，我唯一能想到的就是从废弃的功能中恢复这些提交。

如果不重写历史，我能想到的唯一一件事就是从放弃的功能中恢复这些提交。

如果您使用真正的合并将功能合并到

阶段

，则恢复这些合并很容易。只需使用适当的

-m

参数（通常是

-m1

）在合并提交上运行

git revert

---

如果通过复制提交或快进将功能合并到

阶段

，则会更加困难，因为必须恢复每次提交。您可以为git revert提供一系列要还原的提交，并且它将按照适当的顺序（即从最后到第一顺序）执行所有提交。注意，形式

A..B

的范围意味着“从

B

可以访问的所有内容，除了从

A

可以访问的所有内容”，并且由于

A

显然可以从自身访问，这就排除了提交

A

本身。因此，

1234567..fedcba9

包括提交

fedcba9

和更早的提交回

1234567

，但不包括1234567本身

---

如果您使用

git merge--squash

将功能合并到

stage

，这会将所有提交复制到一个大的（但独立的）提交中，这样您就可以再次在一个复制的提交上运行

git revert

（没有

-m

，因为它不是合并提交）

---

（请注意，无论您如何恢复这些功能，如果最终发现您需要该功能，这有点痛苦。）

如果您使用真正的合并将功能合并到

阶段，则恢复这些合并很容易。只需使用适当的
-m
参数（通常是
-m1
）在合并提交上运行
git revert

如果通过复制提交或快进将功能合并到
阶段
，则会更加困难，因为必须恢复每次提交。您可以为git revert提供一系列要还原的提交，并且它将按照适当的顺序（即从最后到第一顺序）执行所有提交。注意，形式
A..B
的范围意味着“从
B
可以访问的所有内容，除了从
A
可以访问的所有内容”，并且由于
A
显然可以从自身访问，这就排除了提交
A
本身。因此，
1234567..fedcba9
包括提交
fedcba9
和更早的提交回
1234567
，但不包括1234567本身

如果您使用
git merge--squash
将功能合并到
stage
，这会将所有提交复制到一个大的（但独立的）提交中，这样您就可以再次在一个复制的提交上运行
git revert
（没有
-m
，因为它不是合并提交）

（请注意，无论您如何恢复这些功能，如果最终发现您需要该功能，这有点痛苦。）
由于所有已批准的功能都合并到主功能中，因此第一个未合并的提交阶段被放弃。假设F1、F2和F3是舞台上等待客户验收的活动特征。F1为放弃特征，F2、F3为接受特征。所以它需要在舞台上淘汰F1

          C-----…-----D---F1---F2---F3  stage
         /             \
A---…---B---…---E---…---G       master
                \        \
                 F----…----H    prod

您可以使用以下命令：

git checkout stage
git rebase --onto <commit id for D> <commit id for F1> stage

由于所有批准的功能都合并到主功能中，所以第一个未合并的提交阶段被放弃。假设F1、F2和F3是舞台上等待客户验收的活动特征。F1为放弃特征，F2、F3为接受特征。所以它需要在舞台上淘汰F1

          C-----…-----D---F1---F2---F3  stage
         /             \
A---…---B---…---E---…---G       master
                \        \
                 F----…----H    prod

您可以使用以下命令：

git checkout stage
git rebase --onto <commit id for D> <commit id for F1> stage

因此，我们最终只需删除分支
stage
，并从当前的
master
创建一个新分支
stage
。这样，所有未合并的特征都将被删除，并且由于所有特征分支仍然存在，因此它们也仍然可以合并到新的
阶段
分支

因此，我们将一些我们知道目前正在等待客户接受的分支机构合并回
阶段
，并删除了所有被放弃的功能。
因此，我们最终只需删除分支机构
阶段
，并从当前的
主程序
创建一个新分支机构
阶段
。这样，所有未合并的特征都将被删除，并且由于所有特征分支仍然存在，因此它们也仍然可以合并到新的
阶段
分支

所以我们合并了一些分支，我们知道它们现在是w