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.
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...
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With