I have committed some changes (r5,6,7,8) to master and pushed to origin. Other people have pulled. Now master is supposed to be deployed in 2 days, but there is an emergency and something needs to go out today. What's the best practice for this? Do I create a new branch off of r4 and deploy that branch and then merge this branch into master? Someone on IRC said to temporarily revert them, commit, then unrevert them, but am trying to grasp how this would be better or how this works.
可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):
问题:
回答1:
Someone on IRC said to temporarily revert them, commit, then unrevert them, but am trying to grasp how this would be better or how this works.
This would create an extremely ugly history: Instead of r4-r5-r6-r7-r8-fix your history would look like r4-r5-r6-r7-r8-x8-x7-x6-x5-fix-r5-r6-r7-r8 after all the changes.
Creating a branch off "r4" is the best solution. You should have a production branch anyway that is not updated unless something is deployed to production...
回答2:
That's a great idea. git revert creates a commit which cancels out the given commit, so you can do this:
git checkout master git revert <bad commit> # repeat as necessary git push # okay, now master is safe again git checkout -b bugfix git revert <revert-commit> # you've reverted the revert; things are broken again # fix it all up - you have time now git commit git checkout master git merge bugfix git push You could do variations on this, but it's basically the canonical way.