Git 新分支修复 master 分支中的问题后变基或合并

Question

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

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

此 master 已部署到生产环境。

现在我们发现在版本 3 系统中引入了一个错误，导致版本 10, 15, 34, ... 中更多的修复是人们试图解决这个问题并由此产生新的问题。

由于一些提交很重要并且主节点已经部署，我们不能只重置回版本 3。

所以我们从版本 2（就在错误之前）创建了一个分支并按照我们的方式工作包括已提交的相关功能：

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

现在我们想采用 Z 版本并将其合并/变基为我们主人的最新版本。同样，我们希望保留 3 到 100 的所有历史记录。

我们知道一种选择是将 A 变基到版本 100 上，另一种选择是将 Z 合并到 100 中，但我们不确定在这种情况下哪种方法更好。

Answer 1

为什么不记录真实发生的事情呢？您要放弃 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、54、100 被投入生产，然后 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

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

Git 新分支修复 master 分支中的问题后变基或合并

Git Rebase or Merge after new branch fixes issues in master branch

git

git-merge

git-rebase