3 ms·
`git revert` is perfectly suited for this, since it makes a new "inverse" commit of the changes. Your production deploys continue monotonically into the future
by scott_karana 10y ago
`git revert` is perfectly suited for this, since it makes a new "inverse" commit of the changes.
Your production deploys continue monotonically into the future as usual, and you now have version-controlled documentation of the rollback, instead of needing to maintain a separate mapping of production <-> code state.
- pavel_lishin 10y agoDoesn't this assume you only ever deploy one commit at a time?
- scott_karana 10y agoCherry picks and merges are single commits... and fit well for a lot of dev->staging->release branch workflows.
- deleted 10y ago[deleted]
- byroot 10y agoHaving an actual rollback mechanism that brings you back to a known working version is usually way faster than pushing a new version, since it needs to go through CI / Build etc again. At my company rolling back is a matter of a minute or 2, while pushing a revert is more in the 5 to 10 minutes. Your mileage can definitely vary though. However it requires all the shipped changes to be rollback compatible, which isn't that hard with a bit of experience.