Git: revert (or rebase -i) a bad commit out of production
We have been using GitHub flow as the basis for our small development teams branching & merging off
Master was being pushed to
staging (for review) and then
production. One non-approved feature got stuck on staging while a hotfix, so to speak, branched off of master and as such included the as-yet-unapproved code on staging and got pushed to
production. Since then a few more commits have come in on top of that ‘bad’ commit.
We see the need for another shared branch we can use for staging instead of assuming we could share master, but it’s too late hence this question.
- Should I git merge develop into master and then back after tagging?
- How to work with current working copy when moving to old branch in GIT?
- Git: make a branch as master on Github while keeping real master on BitBucket
- Github branch is ahead by 5 commits, how to fix?
- Git: compare local branch to remote staging and production
- Creating branch off of remote master
I’d like to revert that “bad” commit but not sure the best way to do it. There’s a lot of talk on here and elsewhere about ways to do this but because this is in production I want to make sure I understand the ramifications completely.
Pseudo git log of master branch:
* 2ebe3b7 2014-10-20 | merge a new_feature (HEAD, new_feature, master) * 4483c83 2014-10-20 | add second feature (second_feature) * 602bd9d 2014-10-20 | add premature feature (premature_feature) * c341b06 2014-10-20 | add fileB * b7ffb78 2014-10-20 | initial commit
I can either:
git revert 602bd9d
git rebase -i c341b06and rewrite my history without the offending
I don’t have much history “rewriting history” because it’s so taboo to push rewritten history to a shared Git repo.
There are collaborators and
origin/master contains the premature code. What’s the cleanest & safest way to get that single commit off of master (and thus out of production)? Looking for any advice/pitfalls.
One Solution collect form web for “Git: revert (or rebase -i) a bad commit out of production”
Just revert the commit. There is a reason why pushing rewritten history to a shared repo is “taboo”; in that case you have to make sure everybody who has ever used the repo does a
git fetch followed by a
git reset --hard origin/master. The only time one should push rewrites to the server is when one needs to, e.g. when confidential information was accidentally committed.