I think the most powerful tool for fixing mistakes is "git reflog". It doesn't fix everything, but it works very well as long as you view git with the right mental model: a git repo is an ever-growing tree of immutable commits, with branches and tags pointing to the most interesting ones. As long as code has ever made it into that tree (by being in any commit at any time), it's recoverable, and reflog lets you trace your steps back to any point in the past on that tree. Supposedly-destructive operations like amend and rebase actually just build the tree at a different point and move branches to other places in the tree, but (pretty much) nothing in the tree is ever destroyed.<p>For the actually-destructive git commands like checkout and reset, another tool that I'd highly recommend is a "local history" feature in your editor. JetBrains IDEs do this by default, and other editors have plugins for it. It automatically records changes as you make them so you can go back to previous versions of any file. Usually git is enough to save me, but I've also had plenty of times where I make some mistake outside of git commit history and am saved by digging through local history.
Can the main article link to <a href="https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd" rel="nofollow">https://www.codementor.io/citizen428/git-tutorial-10-common-...</a> which is vastly more readable.
I'm sorry, I hate "recipe style" Git articles.<p>Understanding reset and checkout is not hard if you understand the underlying data model. If you don't understand te data model, it's all black magic.<p>Interestingly, I feel the same way about actual recipe books for cooking. It's one thing to keep around as a reference. But if you don't know what a bay leaf tastes like and what it does to a dish, you won't learn anything from someone telling you to use it in a particular recipe.
I found the list helpful, with just about everything I would expect in a list such as this.<p>If I could make one suggestion: I found it to be quite annoying to have to click through to a two-line gist for every single one command. Having those commands be in the article itself would be considerably easier to read.
Another reference site that has come in handy for me for quick reminders, and has a very memorable name -- <a href="http://ohshitgit.com/" rel="nofollow">http://ohshitgit.com/</a>
I advocate:<p>git add -p<p>for interactive staging. It’ll present each hunk of code with a y/n prompt. This is a good habit to prevent committing any debug code or stray marks.
In addition to what nerdponx said about recipe style articles being poor, there are some moderate issues with this article:<p>1. it doesn't clearly say that git checkout with a path is irreversible.<p>2. it says that git reset --hard is irreversible, which is not correct. (see 3.)<p>3. it doesn't mention one of the most powerful git features for fixing mistakes, the reflog.<p>4. git remove is not a git command.<p>5. gitingore is not a git file.<p>6. git-amend is not a git command.<p>7. It doesn't adequately explain why force-pushing causes problems.<p>It looks like clicking through to the gists was such a pain that even the author didn't proofread them.
Mods - please link the original, which has the code fragments inline:<p><a href="https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd" rel="nofollow">https://www.codementor.io/citizen428/git-tutorial-10-common-...</a>
Can someone explain to me the fascination for git, despite the constant stream of "how to fix [<i>insert various git issues</i>]" articles showing it's very difficult to use, at least compared to the alternatives? Most people's work streams only need something as simple as hg, which would also save them a lot of time and hassle.<p>My personal impression is that it's a fashion thing (people think it's cool to waste a lot of time on git, because git is cool and fixing git problems feels like real work, because you're using your keyboard and all that), but maybe someone has a different perspective.
Out of all these, I wish I could use git bisect the most. Working on large codebases with large teams, the command itself is a godsend.<p>Unfortunately a PC with Symantec Endpoint Protection makes the filesystem dog slow to the point that the one time I needed it and it should've taken about 13 steps to find where the bug was introduced, it was faster to redo the feature without accessing the previous code
As much as I like rerere, I have had it result in silently[1] producing the wrong end result. Especially since I merge / rebase frequently, and end up recording lots of small conflict resolutions. Always always always check non-clean merges by hand or you'll eventually be surprised.<p>And sometimes I just resolved it incorrectly once, and now it always does it wrong. Is there a way to make rerere forget a resolution?<p>[1]: relatively speaking. it doesn't fail / pause the operation, so it's "silent", even though it prints out that it applied a conflict-fix.
Was I the only one who was expecting something along THOSE lines? <a href="https://i.pinimg.com/originals/4d/ca/1c/4dca1ce93db819647f2f87fb92769561.jpg" rel="nofollow">https://i.pinimg.com/originals/4d/ca/1c/4dca1ce93db819647f2f...</a>
Need "missing blob" (corrupted git repo).<p>That problem is a depressing one and not uncommon [1]<p>[1] <a href="https://stackoverflow.com/q/18678853/1212596" rel="nofollow">https://stackoverflow.com/q/18678853/1212596</a>