Some bad Git situations and how I got myself out of them

I can&#x27;t believe no one has responded yet with &quot;use a GUI&quot;. After gaining a basic understanding of how branches and merges work, and I do mean <i>basic</i>, I&#x27;ve never been able to screw up a local repo with a GUI client enough that I haven&#x27;t been able to recover with the same GUI tools.<p>I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs provide. If you&#x27;ve made some unrecoverable mistake with an important set of changes, you can always review the history in the same GUI and reimplement the important changes in a new branch.

One of the nice workflows that&#x27;s already built in to the git command line tools is this one. When you&#x27;re working on a branch and realise that a commit you made a few commits back has a mistake in it:<p><pre><code> # Make correcting change git commit --all --fixup=&lt;ref of commit with mistake&gt; # Continue working on branch, then at some point git rebase --interactive --autosquash </code></pre> The --fixup option creates commits with subjects formatted like &#x27;fixup! previous commit subject&#x27;. --autosquash uses these subjects when building the interactive rebase list.<p>Handy enough that I set rebase.autoSquash to true in my ~&#x2F;.gitconfig so &#x27;git rebase -i&#x27; always works like this.

Somebody proposed to use a GUI. That doesn&#x27;t solve the usability issues of Git. There&#x27;s this triangle of what the user tries to do, what the commands and options are called and what they actually do. None of them really align, though with some careful use you can actually make Git do what you want - eventually.<p>I would like to understand what&#x27;s the yearly damage of such an important tool being so difficult to use. People committing the wrong stuff, unmergeable messes, people not being able to correct their mistakes, there must be thousands of Git rookies fucking up their Git repo or throwing away their work just as I am writing this.<p>What would be the cost? Millions of Dollars? Perhaps even billions?<p>It&#x27;s about as bad as 0 being a legit value for a regular pointer.

I absolutely love git now.<p>I&#x27;m still at uni (at a highly ranked but actually crap university where we don&#x27;t learn git properly) and this year was my &#x27;year in industry&#x27; as we call it in the UK, and my first proper experience with git, aside from `git init` at the end of my project and pushing it to a repo.<p>I&#x27;ve become so much more confident with git. Seriously, with one caveat (i.e., you haven&#x27;t pushed your changes to a branch which other developers are working on), it is almost impossible to break irrevocably. Even if you do accidentally break master&#x2F;develop&#x2F;whatever, it only causes a bit of hassle and grumbling.<p>Highly recommend that everyone take a bit of time to learn about &quot;undoing&quot; git commands, whether that&#x27;s through soft resets, hard resets to origin, or the reflog.<p>Reflog is also useful for figuring out how someone else broke something and explaining what they did wrong, since you can see what branch they were on at what commit and what commands they ran.<p>I think git&#x27;s main problem is the somewhat arcane language it uses, and lack of understanding of what&#x27;s actually happening <i>behind</i> those words like &quot;rebase&quot;, &quot;commit&quot;, &quot;patch&quot;, &quot;reset&quot; etc.

A somewhat lesser known git trick that&#x27;s pretty much a strict improvement - use `--force-with-lease` for force pushing instead of `--force`.<p>What this does is check what&#x27;s on the remote branch and compare it with what you think is on the remote branch, and only do the force if they&#x27;re the same thing. So if someone pushes a commit, the force push errors out instead of silently overwriting it.<p>Basically every single time you want to force push, you probably should be doing a `--force-with-lease` instead. I can&#x27;t think of a situation where you&#x27;d want to silently lose commits you don&#x27;t know about rather than get an error.

One thing not covered very well was what to do if you push to origin. My favourite way to fix this: use git revert to create an exact opposite commit to your bad commit.<p><pre><code> git revert &lt;bad commit&gt; git push </code></pre> It leaves a history of the mistake, for better or worse, but it does undo the mistake on origin.

If you&#x27;re concerned about not knowing how to do certain things with git, and understanding at a deeper level how git works, I highly recommend reading Scott Chacon&#x27;s &quot;Pro Git&quot; book:<p><a href="https:&#x2F;&#x2F;progit.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;progit.org&#x2F;</a>

With all these recipies - one thing I do whenever I attempt some stunt in git: I assign temporary tags to every changeset that&#x27;s important.<p><pre><code> git tag tmp git perform-stunt </code></pre> This eases undoing the stunt without needing to find the &quot;before&quot; state from reflog. And if you use a graphical log viewer (I like SourceTree on Mac) you&#x27;ll see the tagged state in the history view - which makes things a lot clearer.<p>And to be aware what happens, there one single explanation of git that helps a lot: <a href="http:&#x2F;&#x2F;eagain.net&#x2F;articles&#x2F;git-for-computer-scientists&#x2F;" rel="nofollow">http:&#x2F;&#x2F;eagain.net&#x2F;articles&#x2F;git-for-computer-scientists&#x2F;</a><p>As soon as you start viewing git as a graph of nodes with branches&#x2F;tags just being &quot;marked&quot; nodes a lot of things make sense, and whatever &quot;git perform-stunt&quot; you attempt it&#x27;s easy to explain within that mental model.

The last addendum reminds me of this inexorably relevant xkcd entry: <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;1597&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;1597&#x2F;</a>

&gt; Oh shit, I accidentally committed to the wrong branch!<p>Other ways to do it (that don&#x27;t require to retype the commit message): - rebase onto the correct branch:<p><pre><code> git branch foo git reset --hard HEAD~ git rebase --onto name-of-the-correct-branch HEAD foo git checkout name-of-the-correct-branch git merge foo git branch -D foo </code></pre> - cherry-pick<p><pre><code> git reset --hard HEAD~ git checkout name-of-the-correct-branch git cherry-pick name-of-the-branch-you-mistakenly-committed-to@{1} (or git cherry-pick HEAD@{2}) </code></pre> &gt; Oh shit, I tried to run a diff but nothing happened?!<p>You probably want to know `git diff HEAD` too.<p>Edit: formatting.

Surprised there was nothing on messed-up merges or rebases. They&#x27;re some of the worst to get out of when you&#x27;re not totally comfortable with git yet.

&#x27;sudo rmdir&#x27;? I don&#x27;t think that does what they think it does.

Based on the article, and many of the comments here, I didn&#x27;t realise how comfortable I have become using git!<p>For example, the last &quot;bad situation&quot; I had to get myself out of involved unreadable .git contents caused by filesystem corruption. If you can &quot;rm -rf fucking-git-repo-dir&quot; then it&#x27;s not too bad; when that fails with an IO error is when things get interesting!

I really like this article but there is a problem with it: what happens if I use one of your techniques and I screw up? These steps you describe are a black box to someone who is no git savvy yet. While these definitely help but they propagate the &quot;git is scary, cross your fingers&quot; mentality. What I mean by this is that the reader won&#x27;t be any wiser after reading<p>&gt; git reset HEAD~ --hard<p>What is ~ after HEAD? What is --hard? Is there a --deep option as well?<p>So I think that you could upgrade this with some annotations over the cryptic parts with a little explanation. What do you think?

Doing mumbo-jumbo between branches with `git stash` is way to hell. Don&#x27;t do it, you lose data. This fucker will unstash changes until first conflict, then it stop and present you with &lt;&lt;&lt;&lt;&lt;&lt;&lt;ID and &gt;&gt;&gt;&gt;&gt;&gt;&gt;ID which nobody understand. Well I understand it, but never know which is which (theirs&#x2F;ours label don&#x27;t help here). You try to undo everything, but then you&#x27;re fucked - all unstashed changes are removed from stash while conflicts are still there. You must be very careful now not to lose changes. You won&#x27;t succeed!<p>That is I believe `git stash` should be removed from git as evil data loosing feature, not needed. Instead just make an alias `git save &lt;TEMP_BRANCH_NAME&gt;` which saves your temporary work to the branch:<p>`save = !sh -c &#x27;export PREV=$(git symbolic-ref HEAD|cut -d&#x2F; -f3-) &amp;&amp; git checkout -b &quot;$1&quot; &amp;&amp; git commit -am &quot;$1&quot; &amp;&amp; git checkout &quot;$PREV&quot;&#x27; -`

Actually the easiest thing is simply not to care about how your log looks.<p>If you don&#x27;t then there are ry only two things you need to know how to do:<p>If you didn&#x27;t push to origin do an ammend. If you did, revert soft and commit the previous code to revert it (you can also put a stash or patch to apply it back).<p>Which frankly is what the article does, basically.

lots of these are unnecessarily complicated:<p>&gt; Oh shit, I accidentally committed something to master that should have been on a brand new branch!<p><pre><code> # disappear the last commit and all changes from it git reset --hard HEAD^ # make a new branch using the last commit git checkout -b new-branch HEAD@{1} </code></pre> &gt; Oh shit, I accidentally committed to the wrong branch!<p>first, you don&#x27;t need to git-add before <i>and</i> after stash, stash will save the working directory and the index (as documented in the DESCRIPTION of git-stash(1)). but for a more logical way:<p><pre><code> # disappear the last commit and all changes from it git reset --hard HEAD^ # get onto the new branch git checkout new-branch # grab the stuff from what was on the old branch git cherry-pick old-branch@{1} </code></pre> &gt; Oh shit, I tried to run a diff but nothing happened?!<p><pre><code> git diff --cached </code></pre> recommended reading for intermediate git users: the DESCRIPTIONs of all of these commands (git-reset(1), git-checkout(1), git-cherry-pick(1), git-diff(1)), and the entirety of gitrevisions(7).

Getting to &quot;Fuck this noise, I give up.&quot; is a very clear indication that you aren&#x27;t competent enough and you should take a GOOD course about git as soon as humanly possible.<p>Shameless plug: <a href="http:&#x2F;&#x2F;engineering.hipolabs.com&#x2F;how-to-work-in-a-team-version-control-and-git&#x2F;" rel="nofollow">http:&#x2F;&#x2F;engineering.hipolabs.com&#x2F;how-to-work-in-a-team-versio...</a>

This doesn&#x27;t even cover half of the bad situations I&#x27;ve gotten myself in over the last few years :D<p>Long term, it&#x27;s best to thouroughly read the man pages, e.g. nicely formatted here: <a href="https:&#x2F;&#x2F;git-scm.com&#x2F;docs" rel="nofollow">https:&#x2F;&#x2F;git-scm.com&#x2F;docs</a>

Another option is to use Mercurial with hg-git to GitHub for network effects.<p>I&#x27;ve been doing that for a while for dropbear ssh, it does hit occasional problems but is overall more pleasant than straight git.

There is no substitute for understanding what&#x27;s going on, especially using a power tool like Git.<p>It&#x27;s a cute website, and useful, I really like it. This sentence,<p><pre><code> Bizarrely, git won&#x27;t do a dif of files that have been add-ed to your staging area without this flag. File under ¯\_(ツ)_&#x2F;¯&quot; </code></pre> just screams to me (a professional Git trainer), &quot;I don&#x27;t understand the Git staging area! I don&#x27;t know my Git fundamentals! Train me!&quot;

I don&#x27;t know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as &quot;spell X solves problem Y&quot; will always break down.<p>Version control systems are an important part of the programmers toolkit and it&#x27;s worth investing a little time to get the fundamentals right.<p>Sure git is not the friendliest of beasts but what it lacks in interface, it more than makes up in internal consistency and trying to learn it &quot;inside out&quot; is a better long term investment than having a list of ways to solve &quot;git problems&quot;.

One of my SO questions could almost fit in there, somewhere before &quot;Fuck this noise...&quot;:<p><a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;28759887&#x2F;git-gc-no-space-left-on-device-even-though-3gb-available-and-tmp-pack-only-16m" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;28759887&#x2F;git-gc-no-space-...</a>

From the section on using `git commit --amend`:<p>&gt; This usually happens to me if I merge to master, then run tests&#x2F;linters.<p>If this happens on more than one occasion, I’d strongly consider creating a pre-commit hook to run tests and&#x2F;or lint the changed files, e.g., I run `checkbashisms` and `shellcheck` as a pre-commit hook when working on shell scripts.

I constantly wonder if there&#x27;s a &quot;better CLI UI&quot; that can be made for git, even if simply a wrapper around git.<p>Ie, if the implementation of Git is right, but only the cli commands&#x2F;etc are wrong.. what would the right UX be? What would a friendly UX look like?<p>Seems like something a lot of people could love - even if blasphemy to Git purists.

Great article. A couple notes<p>Just git reset &lt;ref&gt; should do. The --soft flag is implicit.<p>Amending and rebasing is something you should be careful with. If you&#x27;ve already pushed, you&#x27;ll now need to force push. If another person has put new commits upstream, they will be wiped out irreparably. Not saying don&#x27;t do it, just that it&#x27;s very risky.<p>Instead of deleting and recloning the repo at the end, if you&#x27;re really at that point, just doing git reset --hard origin&#x2F;master should be equally as effective with fewer steps and less time.<p>Pulling down the repo a second time, however, can be more useful for just having a snapshot of the code in a second location that is totally independent of git traffic (don&#x27;t pull to it very often). Say someone force pushes something that removes code. Your snapshot or someone else&#x27;s non-pulled repo is your only hope of getting it back.

I&#x27;ve heard advice from #git on freenode not to use &quot;git commit --amend&quot;, especially on shared repos.<p>I wish I still had a log of the conversation or remembered the exact problem that led up to it, but it involved a simple amend totally screwing up my repo, and I&#x27;ve avoided it since.

I&#x27;ve been debating starting a section of my personal site for stuff like this. Unfortunately it&#x27;s a bit embarrassing, but i figure anything i have to google to learn, it would be beneficial to help others learn it as well. Everything from programming languages (lots of Rust errors are foreign to me, for example), to git issues.<p>I&#x27;ve often had the thought that if everyone did this it could have potential to be quite the open-sourced collection of material - a distributed self-answered Stack Overflow perhaps.<p>Is there any sanity in this? Or would posting everything as self-answers to Stackoverflow be more welcome to the average Googler? <i>(higher ranking, better meta, more likely for the user to see it and community features such as commenting&#x2F;voting&#x2F;editing)</i>

I just uploaded a presentation I gave last February called &quot;Git back on your feet&quot;:<p><a href="http:&#x2F;&#x2F;www.slideshare.net&#x2F;ChristianCouder&#x2F;git-back-onyourfeet-65866467" rel="nofollow">http:&#x2F;&#x2F;www.slideshare.net&#x2F;ChristianCouder&#x2F;git-back-onyourfee...</a>

Great idea! We need more basic git workflows described in plain English.<p>I was expecting some actual &quot;bad&quot; situations based on the title, and to be fair these were bad to me once and are bad for people new to git, but I&#x27;d love to see the level 2,3,etc. version of this article.

You know, a few years back I had exactly the same attitude towards Git. I hated it, tried to approach multiple times and still hated it. But after working with Git on multiple projects, and having developed some deeper understanding of how things work there, I honestly think now that Git is one of the best tools that have been invented over last 20 years for improving the development processes and engineering excellence. I don&#x27;t really want to defend it, the learning curve is apparently pretty steep (at least it was for me), but I would just recommend to not give up and keep trying. There are some good tutorials how to handle it and why it&#x27;s helpful (Atlassian&#x27;s Git book, for instance).

Oh shit, I commited a binary file larger than 100 mb and now i can&#x27;t push to github.com. Solution: <a href="https:&#x2F;&#x2F;rtyley.github.io&#x2F;bfg-repo-cleaner&#x2F;" rel="nofollow">https:&#x2F;&#x2F;rtyley.github.io&#x2F;bfg-repo-cleaner&#x2F;</a>

<p><pre><code> git add . </code></pre> Ugh, no, never do this, never recommend to users to BLINDLY ADD ALL THE CHANGES FROM THE WORKING COPY. I honestly can&#x27;t think of any worse git usage than this.<p>Add the single change you missed, or even better, `git add -p`, to add chunks manually.

The screwed up and committed to master should end with:<p><pre><code> git reset --hard origin&#x2F;master </code></pre> (assuming that the remote is called &quot;origin&quot;) With the example in the text, you have to know the number of commits you&#x27;ve made to master.

&gt; Bizarrely, git won&#x27;t do a dif of files that have been add-ed to your staging area without this flag<p>Not sure what&#x27;s bizarre about that. Doing so helps keep your commits clean and helps git tools (diff, git-gutter, etc) by ignoring things you&#x27;ve already stated are complete.<p>For example, I quickly fix a bug. The code is ugly and I don&#x27;t want to commit it yet. So I add the bugfix files. Then I clean up the code (before commiting). Now I can do another diff between the staged and unstaged files, checking that it looks better than before, and still works. This way there is 1 clean commit &quot;bugix&quot; and not 2 commits &quot;bugfix&quot; and &quot;bugfix code cleanup&quot;

I managed to &quot;rm -rf .git&quot; at one point. Took me about a minute to realize and -surprisingly after &lt;c-c&gt;-ing i lost nothing (as far as i was aware). Git is freaking hard to break. Also always remember git-reflog, it safes lives.

Also great for getting out of Git messes: <a href="http:&#x2F;&#x2F;justinhileman.info&#x2F;article&#x2F;git-pretty&#x2F;" rel="nofollow">http:&#x2F;&#x2F;justinhileman.info&#x2F;article&#x2F;git-pretty&#x2F;</a>

I prefer stackoverflow for things like this as I can see from comments and up votes whether the command does what the poster claims, or whether it is going to make things worse for me.

Nobody likes to read manuals or books, due to which one can see FAQs being posted on Q&amp;A sites.<p><a href="http:&#x2F;&#x2F;gitready.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;gitready.com&#x2F;</a> contains a number of small articles categorized by beginner, intermediate and advanced that might be helpful.<p>Another resource for commonly used git tips and tricks: <a href="https:&#x2F;&#x2F;github.com&#x2F;git-tips&#x2F;tips" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;git-tips&#x2F;tips</a>

I moved to git at the begining of this year and I must say that I miss SVN. But everyone keeps telling me that git is better so I&#x27;m sticking to it.

Well, there are many more situations you can get into.<p>Like cherry picking, force pushing, merge --no-commit, rebasing... almost any operation can end up going wrong.<p>Just pay attention.

<p><pre><code> # create a new branch from the current state of master git checkout -b some-new-branch-name # remove the commit from the master branch git checkout master </code></pre> Or just `git branch some-new-branch-name`...<p><pre><code> cd .. sudo rmdir nsfw-git-repo-dir </code></pre> That will only remove it if it&#x27;s empty? Which it never will be, because there&#x27;s at least `.git&#x2F;*`...<p>Still, amusing :)

Fucking love it.<p>alias gitshit=&quot;open <a href="http:&#x2F;&#x2F;ohshitgit.com&#x2F;&quot;" rel="nofollow">http:&#x2F;&#x2F;ohshitgit.com&#x2F;&quot;</a>

It&#x27;s probably a good time to check if you have some safety against `rm -fr `.<p>Two days ago, I wanted to delete .git only, but accidentally as my fingers were accustomed with -fr , the command was `rm -fr * .git`. Rails server was running and some hope arose at the moment to just `lsof | grep` .. unfortunately that didn&#x27;t work with me !<p>Ironically, all dot files have stuck as obvious :)

git to me is a work of art. There is a lot of complexity underneath but the end user sees something that is simple, fast and easy to use. It scales depending on user needs and It&#x27;s easy to reason about.<p>This is a feat of engineering, to take something complex and make it easy for anyone to undestand and use. It shows real expertise and deep understanding of the area.<p>In many ways it&#x27;s a shining example against the &#x27;culture of complexity&#x27; that we increasingly find ourselves in. Here rather than simplying the objective is to be to make thing as complex as possible, usually in pursuit of extremely niche use cases or because either the expertise or the interest to simplify is not there. If git was designed in this culture it would be fragile, full of buzz words, poorly documented and prone to failure, and something only a few self appointed experts could reason about and use properly.

&gt; <i>This usually happens to me if I merge to master, then run tests&#x2F;linters... and FML, I didn&#x27;t put a space after the equals sign.</i><p>Am I the only one that runs my tests before committing, let alone merging to master?

&gt; Oh shit, I committed and immediately realized I need to make one small change!<p>If you don&#x27;t want to change the commit message, in addition to --amend:<p><pre><code> git commit --amend --no-edit</code></pre>

The post is missing the most important command : git --help

It would be nice to add these two:<p>Oh shit, someone checked-in huge file that shouldn&#x27;t be in repo.<p>Oh shit, this folder I had been working on should have been in its own repo.

for the rest of it there is <a href="http:&#x2F;&#x2F;git.io&#x2F;git-tips" rel="nofollow">http:&#x2F;&#x2F;git.io&#x2F;git-tips</a>

why do you run git add . before git stash?

The last rmdir example should be rm -rf.

I fear Git so much that I make zip packages of the repo before potentially destroying operations.

One of my favorite teachers in school was a dude-bro programmer who pretty sure as younger than me. He&#x27;d spent a summer at Google and made us use git and gerrit. I&#x27;m honestly a much better programmer thanks to him. I&#x27;m still using the git cli to this day.<p>I also still say &quot;new up&quot; an object thanks to him. I&#x27;m not so proud of that one.

Most of the time, stay calm. Do not `git push` hastily, and check `git status` if you can :)

Surprised he finds git to be complicated. It probably is deep down, but for day-to-day use, compare it to SVN.<p>Until I switched, there was always a panic when branching or merging. With git, I can branch like a nutter and things seem to still work out in the end.<p>Not sure why, perhaps someone else has a perspective on it.

All of those things and more are way easier to do with gitk and git gui.

If the owner is here: with javascript disabled the code is unreadable.

maybe also useful <a href="https:&#x2F;&#x2F;gitlab.com&#x2F;esr&#x2F;reposurgeon" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;esr&#x2F;reposurgeon</a>

The last one is my usual tactic.

It is not the fault of Git if to use it you have to know it!<p>However would appreciate a quick and dirty handbook.

LOL. Bookmarking along with my other Git reference sites...

Not quite in the spirit of this article, but &quot;I just want this &#x2F;one&#x2F; file without the rest of the changes from branch foo&quot; is something I use all the time<p><pre><code> git checkout otherbranch git checkout firstbranch -- fileIwant maybe1more git commit -m &quot;brought over files&quot;</code></pre>

Git is complex and nuanced, and short term purple think it&#x27;s faster to memorize some commands instead of understanding the fundamentals.<p>I kept having problems with git, so I read a fucking book on it <a href="https:&#x2F;&#x2F;git-scm.com&#x2F;book&#x2F;en&#x2F;v2" rel="nofollow">https:&#x2F;&#x2F;git-scm.com&#x2F;book&#x2F;en&#x2F;v2</a><p>I&#x27;m not saying I never get into situations I can&#x27;t get myself out of, but the examples in the oh shit website now look like obviously trivialities.

Is the documentation really that bad? Would it benefit from a technical writer going over it? Is the project open for discussion on changes to the documentation?

Yep, git sucks but it&#x27;s all the rage now. Mercurial is 100x nicer to use and logical, but since it&#x27;s written in Python it&#x27;s slow as molasses, especially with large binary files.<p>Next on the list: Larry McVoy&#x27;s Bitkeeper promises to be everything git and Mercurial aren&#x27;t. (git is &quot;inspired&quot; (read: copycat) by Bitkeeper).<p>It&#x27;s funny how <i>Sun Microsystems</i> influenced the industry in so many ways, isn&#x27;t it?