1

情况

我们为我们的网站制作了一个特殊的促销版本，管理层要求它进行直播，我们做到了。假设从普通站点开始（为简单起见，将其称为 commit 0），我们花了 5 次提交来创建促销版本，并且所有这些提交都是在 master 上进行的（因此工作的促销站点是 commit 5）。

现在我们接到了紧急电话：最初给我们的促销日期是错误的，促销应该要到下周才能开始。请立即回滚到原站点。

假设以下

  1. 我们在 origin 上有一个接收后挂钩设置，它将实时推送它收到的任何提交。
  2. 我们需要该站点立即回滚以提交 0。
  3. 大约一周后，我们将再次需要对提交 5 进行的更改。
  4. 我们预计从现在到下周之间会添加一些错误修复。

问题

什么系列的 git 命令适合解决这个问题？

这是一个想法，我认为它会起作用，但似乎不是最理想的：

  1. git branch promo保存我们的促销工作以备后用
  2. git reset --hard 0回滚到正常站点
  3. git push -f origin master再次推送正常网站直播。我们需要“强制”标志，否则 git 会抱怨 origin 领先于我们的本地分支。
  4. 在提交 0 之上的 master 上做一些错误提交，在一周内创建提交 6 和 7。
  5. git merge promo下周到来的git push origin master时候，是时候真正重新推出该网站的促销版本了。

那么，有没有更好的方法来做到这一点？我应该使用还原而不是重置吗？有没有办法避免尴尬的-f强制标志？其他的建议？

4

2 回答 2

2

作为一项规则，我不喜欢重写历史。变化总是在向前推进。我会这样做。

# Keep a copy of the promo state
git branch promo

# Undo the changes
git revert 0
git push

在“促销”分支上做你的工作。你可以变基，从“master”合并，做任何你喜欢的事情。

然后，真的是时候了：

git merge promo
git push
于 2013-10-22T08:37:19.530 回答
1

对于第 5 点，我宁愿promo在master.

 git checkout promo
 git rebase master
 git checkout master
 git merge promo     # fast-forward master HEAD to promo HEAD
 git push

这样，您可以在测试促销与您所做的错误修复（提交 6 和 7）的集成时保持线性历史记录。

于 2013-10-22T08:28:29.827 回答