We have been using GitHub flow as the basis for our small development teams branching & merging off master. 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.
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 c341b06 and rewrite my history without the offending 602bd9d commit.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.
Thanks!
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.