Question

比如说，你已经在服务器的webroot中推送了一些提交并将它们投入生产。然后出了点问题。显然，通常你想要做的是暂时将webroot中的文件恢复到以前的某个状态，然后返回到你的本地开发地点，修复破坏的东西，测试它，在破坏某些东西的提交之上提交并推送这些新修复提交给主分支。然后再次转到生产webroot并将所有内容提取到最新提交，以便一切都得到修复并正常工作。然后每个人都可以拉出主分支而不用担心破坏提交或重置git head或其他令人沮丧的事情。

所以：这是一种合法且安全的方法吗

在生产webroot中，在主分支

上

>git log --pretty=format:"%h %ad | %s [%an]" --date=short

0fu83bd Wed Mar 6 17:47:42 2013 | Merge branch 'sample' [developer1]
fd442f8 Wed Mar 6 17:47:10 2013 | Some updates [developer1]
ad84471 Wed Mar 6 17:25:12 2013 | Added something [developer2]

找到您要暂时还原文件状态的提交，例如 ad84471

>git checkout ad84471
>git branch
* (no branch)
  master

去任何你开发，修复，提交，[合并]，推动主分支的地方。执行此操作时，生产文件处于ad84471状态，没有人修改它们。然后回到生产webroot：

>git checkout master
>git pull
>git branch
* master
>git log --pretty=format:"%h %ad | %s [%an]" --date=short
7guffbd Wed Mar 6 17:47:42 2013 | Fixed 0fu83bd bugs [developer1]   <---new commit
0fu83bd Wed Mar 6 17:47:42 2013 | Merge branch 'sample' [developer1]
fd442f8 Wed Mar 6 17:47:10 2013 | Some updates [developer1]
ad84471 Wed Mar 6 17:25:12 2013 | Added something [developer2]

现在我们在主分支中，一切正常。每个人都只是拉出最新的变化并且很高兴。

我已经使用md5deep检查了文件，以确保一切都返回（在修复之前）到我们已经恢复的状态：

>md5deep -rel webroot > hashes_master_before_checkouting_ad84471
>git checkout ad84471
>git checkout master
>md5deep -rel webroot > hashes_master_after_checkouting_master_again

这些哈希之间的差异只显示

webroot/.git/logs/HEAD
webroot/.git/index

已经改变了。

所以这似乎是快速修复某些东西的好方法，或者说我错了？

免责声明：我知道在许多项目中这违背了预期的工作流程，并且这种做法不太好，而且以前应该进行自动化测试，但对于开发人员很少的小项目，通常不会可行或实用，因此与使用git reset或revert相比，这种方法可以节省大量时间并简化操作。

Answer 1

对我来说似乎很紧急。

如果你想要更加“严谨”，你可以从“已知良好”提交创建一个分支，并检查生产，因为它留下了更多的审计跟踪。

在开发机器上：

git branch hotfix-20130307 ad84471
git push origin hotfix-20130307

在产品机上：

git fetch
git checkout hotfix-20130307

然后修复主分支后，再次在prod机器上检出主机并更新它：

git checkout master
git pull

这样做的好处是，如果有人去了prod机器并运行git branch，他们会获得更多信息，并且可以在bug跟踪器中找到hotfix-20130307分支的一些记录，并且知道为什么要这样做。如果它是一个小团队，并且唯一可能看到prod机器的人已经知道情况是什么，那么可能是矫枉过正。

Git：暂时还原推送提交

1 个答案: