Git在新分支修复主分支中的问题后重新设置基础或合并

我们有一个具有多个提交的主分支：

1 -> 2 -> 3 -> 4 -> 5 -> ..... -> 100

此主机已部署到生产环境中

现在我们发现，在版本

3

中，系统引入了一个bug，导致版本

10、15、34、

中有更多的修复，人们试图解决这个问题并由此产生新的问题

由于一些提交很重要，而且主服务器已经部署，所以我们不能只重置回版本3

因此，我们从版本2（bug之前）创建了一个分支，并按照我们的方式工作 要包含已提交的相关功能，请执行以下操作：

1 -> 2 -> 3 -> 4 -> 5 -> ..... -> 100
      \
         A -> B -> C ...........- > Z

现在，我们希望采用

Z

版本，并将其合并/重新设置为我们的主控器的最新版本。 同样，我们希望保留3到100的所有历史记录

---

我们知道一个选项是在版本100上重新设置A的基础，另一个选项是将Z合并到100中，但我们不确定在这种情况下什么是更好的方法

为什么不记录下真正发生的事情？您放弃了3..100系列而选择了A..Z系列，因此请记录：

git tag -m "3 was so bad we abandoned the branch here" abandoned-master master
git checkout -B master better-version

生产

... 1---2---3 ... 100   abandoned-master
         \
          A---B ... Z   master

如果您的生产环境保持了提交投入生产的合理日志，任何人只要查看这些日志和git的历史记录，就会清楚地看到发生了什么：提交3、10、54100投入生产，然后Z投入生产。这里发生的事情是非常清楚的

添加谎言

# as above, then
git merge -s ours -m "not really a merge, ^2 is abandoned history" master@{1}

... 1---2---3 ... 100     abandoned-master
         \           \
          A---B...Z---*   master

---

或者更彻底地歪曲历史的再基地会主动隐瞒相关事实。任何使用伪造历史记录的人都不会得到帮助。

您想让Z成为您的新主分支？您想将新分支与主分支合并/重新设置基础，还是想将新（1-Z）分支推送到生产的主分支？这听起来是一个非常好的解决方案。我关心的是：版本1-100也在Jenkins中构建，所以它知道他们，他们可以在Jenkins的历史中看到。如果我们按照你的建议去做，詹金斯现在将如何对待版本3-100的历史版本？如果你做了重新基址，它将如何对待它们？詹金斯的工作是部署你让它部署的东西，并记住它所做的事情，而不是对其职权范围之外发生的事情强加武断的规则。