How to undo almost anything with Git

https://github.com/blog/2019-how-to-undo-almost-anything-with-git

by agonzalezro • 11 years ago

411 91 11 years ago

alphydan• 11 years ago

until this happens: http://renooble.tumblr.com/post/18845123629/git-funny-scary-...

mmanfrin3• 11 years ago

My only real git crisis was when I accidentally `git push -f`ed what I thought was my own branch, but actually the `develop` branch. On a monday. After a weekend where about a hundred commits had been cherry picked and merged in to develop by a dev not in the office. None of my coworkers had recent versions of develop.

The thing that ended up saving me was our CI -- we autodeployed passing builds to our staging env; so we were able to ssh in and `git push -f` back from staging to our repo.

herge• 11 years ago

For what it's worth, you could have looked at the reflog of the git repo on the server and it would still have a reference (the hexadecimal hash) to the develop branch before your git push -f.

mmanfrin3• 11 years ago

We had the hash, but no one had it locally and we could not pull it down since I had overwritten the history.

dsp12342• 11 years ago

Git generally doesn't delete commits until a garbage collection is done (and assuming no other references). If you find yourself in this situation again, then try:

git reflog show remotes/origin/develop

This will show the reflog for the branch, then you can find the hash just before your push, check it out, then force push it back.

I've recovered from other developer's accidental force pushes in less than 5 minutes, with no commits lost.

jordigh2• 11 years ago

But if the remote has advanced since you pushed, you'll still need to reflog on the remote server, right?

_ikke_• 11 years ago

I always recommend people to use `git push --force-with-lease`. It's more to type, but it verifies if the remote branch is the same as the remote tracking branch, so you don't accidentally rewrite branches someone else has pushed to.

rectangletangle• 11 years ago

You can just alias it in your bash profile, if it's too much to type.

alias gitpushf='git push --force-with-lease'

jordigh2• 11 years ago

Mercurial Evolve is a safe and distributed alternative to `git push --force`:

https://www.youtube.com/watch?v=4OlDm3akbqg

matwood2• 11 years ago

Places like bitbucket let you mark branches (like master and develop) as non-deletable and non-rebaseable. Basically it prevents errors like yours.

smtddr• 11 years ago

Seriously. I don't understand why github doesn't provide at least the ability to lock the master branch against any action other than a merge from another branch. Merging a branch that causes major damage is unlikely if there's any kind of review process and generating a revert to "undo" that damage is a one button thing in the github-webUI if you do it immediately, or at least before master gets other commits on top of it. But I'd think everyone's workflow would stop because they'd have a ton of conflicts from a screwed up master.

In fact, let me ask HN. Does anyone work in a place where devs commit directly to master? I can't even imagine that workflow. Everything I've seen or heard of is PullRequests, code-review, +1, then merge to master.

sytse• 11 years ago

GitLab CEO here, in GitLab we do this too and call it protected branches, your master branch is automatically marked. See https://about.gitlab.com/2014/11/26/keeping-your-code-protec...

chjj• 11 years ago

My most recent major git crisis wasn't reversable by git.

A little while ago, I accidentally did a `git clean -xdf` on my home directory (wrong tmux tab). I index my home directory: just the most important config files, among other notes and text files. That `git clean` call wiped half my home directory before I realized what was happening and frantically tried to ^C and ^\ it. I had to find other ways to recover my files.

The deleted files weren't essentially important, which is why I didn't back them up frequently or index them, but they were moderately important. That was a bad day.

I realize it's probably better to dump everything in ~/.config and index that instead, while maintaining symlinks in ~/. It was just the way I had it set up.

leni536• 11 years ago

I suggest to use GNU stow for managing config files and keep your repo in a separate directory.

tomjen3• 11 years ago

How is this not undoable with whatever the reverse merge command is?

Second why ever use force merge?

erikb5• 11 years ago

Maybe that was why I always `git fetch && git push -f`. But luckily since a few months it's not a problem anymore if you configured your git correctly, because now it only force pushes your current branch.

Peaker• 11 years ago

Just make an alias pushf = push --force-with-lease, and it becomes even less to type! :-)

Kiro• 11 years ago

What kind of workflow do you use where a git push -f is necessary? Just curious, I'm no git expert.

thyrsus2• 11 years ago

Something I'm still working out....

I have a directory tree full of test data. As the project goes along, the test data will evolve, and thus should go under revision control.

Testing needs to start with known files, so, hey!, git checkout test_data - except that means my latest code revisions need to go into the test_data branch even before they're tested :-(.

Then the tests make their changes to the data, which the tests check, and which I then want to throw away. So: "git checkout test_data -f; git clean -f" -- except that cleans out the source code area as well as the test data area.

I'm thinking the test data should be separate repository. Is that a mistake?

[Edit] I've tried looking at stackoverflow.com, but searching for "git testing" returned ~7000 articles, the first few hundred of which didn't look relevant.

nothrabannosir• 11 years ago

try putting test data templates in test_templates (under rev control), and doing rm -rf test_data, cp -r test_templates test_data at the start of your testing routine. Put test_data in .gitignore.

does that help?

lmm4• 11 years ago

Keep the "pristine" version of the test data in src/ (checked into git), have the build process copy it into target/ (or build/ or whatever you want to call it; either way, ignored in git) before starting testing.

thyrsus2• 11 years ago

Thanks! On the one hand, git seems to restore the test data to its initial state faster than rm -r; cp -r, but I'm getting a strong hint from these answers that keeping the test data explicitly in sync with the code is worth the minor delay.

phaemon2• 11 years ago

You can do:

git checkout test_data 'testdata/'

to only grab the 'testdata/' directory from that branch. You can do this with files with a pattern, like '*.c', as well.

pjc50• 11 years ago

Sounds like something that would be a lot easier to handle with "svn revert"..

lmm4• 11 years ago

Only if you're looking for excuses to prefer svn. You can do the exact same thing you would with 'svn revert' with 'git checkout --'.

johnnymonster• 11 years ago

This does not cover the only scenario which I was hoping it would. I accidentally pushed my api key/password to github and I want to "undo" that push and completely remove the history locally and on an origin? This is so obscure across many different outlets. And go ahead, flame me for pushing my password/api key to github, but all of you know you have done this at least once in your life!

akerl_• 11 years ago

https://help.github.com/articles/remove-sensitive-data/

That said, as the article points out, you need to consider them compromised once they've been pushed and rotate the creds.

pimlottc• 11 years ago

To add to this, this is not just good paranoid practice. Don't just think you're safe because you fixed it 5 minutes later and probably no one noticed. There are sites that monitor the global github commit feed looking for things like AWS credentials and SSH keys. If it's been pushed to a public github repo for even a moment, it's been grabbed.

seanp2k22• 11 years ago

It's still useful to know how to use e.g. BFG for e.g. Situations where you push a password to private git / GH :)

hrez• 11 years ago

If it is a public repo it's compromised, period. Change keys/passwords ASAP regardless of what you do with the repo.

guiambros• 11 years ago

If you pushed something (publicly) to GitHub, there's no undo: you HAVE TO change your keys now. Your keys were immediately ingested and compromised a few seconds after you pushed, and likely even before you realized what you've done.

To paraphrase from my own comment last month [1]:

"Some time ago I published my blog to GitHub, with my MailGun API key in the config file (stupid mistake, I know). In less than 12 hours, spammers had harvested the key AND sent a few thousand emails with my account, using my entire monthly limit.

Thankfully I was using the free MailGun account, which is limited to only 10,000 emails/month, so there was no material damage. And MailGun's tech support was awesome and immediately blocked the account and notified me, reseting the account after I had changed the keys."

If you're wondering how they were able to harvest GitHub commits so quickly, just read the article linked in that thread [2]. Basically you have bots drinking from GitHub's events firehose and the GHTorrent project. Every commit is monitored and harvested for passwords on the fly.

[1] https://news.ycombinator.com/item?id=8818035

[2] http://jordan-wright.com/blog/2014/12/30/why-deleting-sensit...

seanp2k22• 11 years ago

Nice, so now we need to make honeypots which post to GitHub tons of things that look like real secrets but with broken credentials, monitor logins for those things, and start a blacklist of compromised / malicious systems (which would be the things trying with those logins).

Zardoz84• 11 years ago

This last week, I accidentally pushed a github apikey (my dot files repo). Github send me an mail saying that they disabled these api key, on less that 1 minute. So, I created a new api key, and I changed my fish config file to read the api key from an private file.

crimsonalucard2• 11 years ago

as great as git is, I wish there was something more intuitive. Git is definitely one of the more confusing tools out there.

VLM• 11 years ago

I'm curious if you don't like the concepts of how it works or the UI or maybe the workflow.

A workflow example would be doing a rebase after a push is almost universally seen as naughty so why permit it without some kind of UI like --I-really-know-what-i-am-doing=yes or something?

WRT the UI itself, I've read a couple people claiming the emacs magit package is easier to use than the CLI itself, which would isolate the problem to the GUI. I have not personally invested the time into magit and would find comments on that theory by people who have experimented to be interesting.

http://magit.vc/

zyxley3• 11 years ago

Git's CLI is just awful in a bunch of ways. There's a bunch of commands that do two or more different things depending on how you use them, and whole piles of cryptic and incomprehensible error messages.

Heck, the just the contrast between `git add <file>` and `git reset HEAD <file>` is terrible.

angdis• 11 years ago

There is NO particular workflow built into git. Teams have to reach an informal agreement on how they're going to use it, otherwise chaos ensues.

albinofrenchy2• 11 years ago

Honestly? There kind of is -- https://mercurial.selenic.com/. I learnt mercurial first but have now spent about 3x as much time with git and I still find mercurial to be more intuitive.

crimsonalucard2• 11 years ago

Cool. The problem is git is already pretty much ubiquitous. Would it be possible to put a mercurial like UI on top of git? Does one exist yet?

barrkel3• 11 years ago

Git is the easiest to work with SCM I've used, however I've only used SourceSafe, cvs and svn before.

Once you grok that it's more or less an immutable DAG with diffs for edges and hashes for node names, that tags are read-only labels for hashes and branches are read-write labels for hashes, all possible operations are obvious; you just need to find the right incantation.

The concept of git being so simple is what makes working with it much easier than something like svn or cvs, where doing the equivalent of a rebase, cherry-pick or merge of a diff into multiple different branches is sufficiently difficult that I developed my own tools and workflow to get around them. When I had to work with svn writing bug fixes or doing development, instead of committing my work, I saved my work to patch files which I saved / reapplied when I switched branches. I developed scripts to do 3-way merges. I haven't had to do any of that crap with git. Git is far more logical. It's just missing a consistent command-line UI.

Someone2• 11 years ago

"Once you grok that it's more or less an immutable DAG"

That's problem #1. More or less immutable = mutable. Other SCMs limit mutations to additions and use a separate command (svnadmin) to do things that may permanently lose information. The svn repository may be ugly, but it can be relied on to store history.

"you just need to find the right incantation."

Incantation is the right term. As you admit, it's "just" missing a consistent command-line UI.

The combination of these two makes me very weary whenever I do anything remotely difficult in git.

A third thing that scares me is the ease with which people talk about things still being there "as long as git hasn't garbage collected them". To me, that sounds like having a memory allocator with an 'unfree' call that you can use to try and recover accidentally freed memory.

erikb5• 11 years ago

Only as long as you don't learn it. If you really need to use git often, please take the time and go through the git book. Then most things make sense and using git becomes way more stable.

It's a powertool for power users. It sks that it became the major tool of our time, but that doesn't change it's design decisions. (And I'm a huge git fan. But I'm also a power user who is happy to spend weekends to learn all the details about such a tool)

npongratz• 11 years ago

I've used the following flow chart to help determine strategies to get myself out of messes:

http://justinhileman.info/article/git-pretty/

Just another way of presenting similar information. No affiliation, just a satisfied consumer of the info :)

mikekchar3• 11 years ago

Ha ha! I like the part of the flow where it goes: "Is anyone downstream?" -> yes -> "Enough to form a lynch mob?" -> no -> "Do you hate them?" -> yes -> "We're going to do an interactive rebase".

joshribakoff2• 11 years ago

I use this one. Also the same information, but its in paragraph form like the OP, but with hyperlinked questions to jump around like you would in a flow chart.

http://sethrobertson.github.io/GitFixUm/fixup.html

ocdtrekkie• 11 years ago

This is pretty useful for Git noobs like me.

js2• 11 years ago

Was this taken from https://news.ycombinator.com/item?id=9661349 or is it just a coincidence?

chriscool• 11 years ago

Instead of "git reset --hard stuff", I recommend "git reset --keep stuff" as it will not delete uncommited files in the working directory.

jgraham• 11 years ago

That is reasonable, depending on what you are trying to achieve,, but I think the explanation you gave is a bit misleading. Neither --hard nor --keep affect files that have never been comitted. The difference is that --keep aborts if it would affect a file that is tracked, but has uncommitted changes.

nbouscal• 11 years ago

This is pretty good, I had never seen autosquash before. Another rebase flag that I find useful is --onto. For example, to rebase only the most recent N commits of a branch onto master:

git rebase HEAD~N --onto master

daxelrod• 11 years ago

See also http://sethrobertson.github.io/GitFixUm/fixup.html which has helped me immensely in the past.

chx• 11 years ago

Though I walk through the valley of the shadow of rebase, I will fear no evil: for reflog are with me (sorry, couldn't resist)

forrestthewoods• 11 years ago

I'm so glad I use Perforce. Yeah branches are a bit cumbersome. But it's idiot proof. There is literally no way for any artist to cause irreversible harm. They can't even do harm that isn't easy to fix with a few clicks in an easy to use, easy to understand, easy to discover GUI.

I suppose one of the key features of Git is the ability to rewrite history. It makes a lot of sense in the context of an open source project pulling in changes from the wild. For most of us such utilities aren't just useless they're actively harmful.

Never leave me P4. Please God never leave me.

jebblue• 11 years ago

With Git though, I can and do have many micro repositories scattered around my disks. My bin and Documents directories almost always have their own repositories each. Git works great for this as well as being a tool to help teams with code management. I do have to Google a lot of stuff for it but it works really well and this article is a good summary.

erikb5• 11 years ago

I'm a huge git fan but I have to agree. At least some of the VCSs out there should be non self-destructive. Git is really bad if not all users of a repo take the time to learn to use it efficiently.

learnstats2• 11 years ago

Git is really bad if not all users of a repo take the time to learn to use it efficiently.

The "if" clause here happens rarely enough that I can quote just the first four words of the sentence: "Git is really bad."

There are 2000 words here on how to undo.

gambiting• 11 years ago

I always used to swear by Git, until I started working at a company that uses Perforce. It's literally fantastic and I want to use it for all projects now.

vacri• 11 years ago

One particularly tricky thing that this page doesn't mention is removing binary blobs (or any file) from the history. Someone committed tens of megabytes of binary stuff to one of our repos. A later commit 'fixed' this by removing them. But those binary blobs are still there, because it's a historical commit, meaning every time you clone the repo (or similar) you get huge amounts of crap.

Maybe --squash will fix it? Something to look at, I guess.

Skinney• 11 years ago

As far as I know, you need to use rebase --interactive and delete the commit(s) that introduced the blobs. This will, however, create a new tree which can be painful for everyone involved.

jokoon• 11 years ago

git checkout is what I want to do most of the time, but I always have been confused with svn checkout, so I never could remember it.

How to undo almost anything with Git

Related Stories