Git push -f # Force you history rewrite onto the remote branch, you utter monster! You can happily rebase a branch that is already pushed to remote by running: git rebase origin/master -i Important Notes on RebaseĪs previously mentioned, when you rebase the commits since the common ancestory are rewritten and given a new hash id. Now when I push this to remote it won't carry the credentials with it. Our offending commit as been modified so the credentials are no longer present. As we have none, the rebase will complete and we can now see: To move on to the next commit flagged as reword or edit. I'll commit that change and return to the command line. As I've modified out the lines in my Web.config I can add the file back to the commit to get this: See what I mean about rewriting history? Now we can change this commit to our hearts content. Then, open git gui with the below command and select "Amend last commit": git gui Now let's go to our IDE / Text Editor and remove the offending lines from the file. Once it gets to any commits labelled reword or edit it stops like so: This will then take all those commits and re-create them (with new hash ids, we'll talk about that in a sec) on top of the point you picked as a starting point (here it's where we branched off master).
This is supremely useful in a non security breach context too if you wanted to clean up a commit log, get rid of a series of "Revert x, Revert Revert x" style messages etc.įirst I'll mark the offending commit with "edit":
If we had lots of commits with 1 offending commit in the middle, we could keep all of those commits and just edit out the one in the middle. We can choose to reword the commit messages, change the contents of the commit or squash (combine) multiple commits together to give clearer context in the commit log. Here's the magic rebase effectively allows you to rewrite history from a common ancestory. This will bring up a list of the commits made between our local master branch and the head of the NewFeature branch. Anyone who peeked in the commits will still be able to see them.įinally, we could instead run: git rebase -i master This will create a new commit that reverts the changes, unfortunately the credentials are still there, just not at the head revision.
We could alternatively run: git revert 14c52c3 This works, however if we've got a lot of new commits and the unsafe one happens somewhere in the middle, we may have lost a lot of good context in the commit messages. gitignore or clean out the credentials then check in again. This would allow us to add the config file to. This will remove all commits on our current branch back to commit "07784e1" (assuming this is the last safe commit) but keep our new and modified files. So this isn't good, but there is a light at the end of the tunnel we've not pushed to the remote server yet, so can undo the mistake. Whilst Amazon to sometimes refund these sort of attacks, by default you are liable for the costs, which can go over $3,000! Did you know there are scripts running against GitHub that crawl for AWS credentials? Once they get your details they setup 100's of servers on your account to mine bitcoins. Suddenly you've checked in your credentials to your local branch. So you're busy coding away, get the website to a stable stage and do a git add -A then git commit -m "Oh dear!". Part of your website accesses an AWS service like S3, DynamoDB or SQS, so naturally you may have your AWS access key and secret stored in a config file (we'll talk about WHY YOU SHOULD NEVER DO THIS at the end).
Let's say you've got a public repository on GitHub where you're building a basic website hosted on AWS.