10 Common Git Problems and How to Fix Them

Michael Kohl on July 09, 2018

I originally wrote this article for Codementor in October 2014. It should have something for everyone, from fairly new git users to experienced d... [Read Full]
markdown guide

One obscure trick that I've had to use a few times in the past is that until you prune objects from .git via git-gc or git-prune, they're still under .git. So if you git-add a file and accidentally git reset --hard, you can still recover it through some Git object database spelunking - even if you didn't commit!


Yep, git keep the files for 30 days at the trash area


Whoa, thx for that, going to be life saver tomorrow.


I strongly recommend to all careful developers to never use rerere.

Resolving a conflict does not sure that you resolved it correctly, as some bugs are only discovered quite a while after the conflict resolution is done. Therefore, you certainly would not want Git to remember conflict resolutions and replay them automatically. Even though it is possible to purge the rerere DB, nothing guarantees that you would remember to do so when re-doing merges.

It is such as badly designed "feature", that if rerere.enable is not specified to any value, and the current repository has a rerere DB, it will be enabled in conflict resolution. Therefore, it is best to have:

git config --global rerere.enabled false

I prefer a rule of thumb, that if you find yourself repeating the same conflict resolutions over and over, then your development process could be wrong and you need to rethink the process.


I have to agree on this one. I've been burned by rerere on multiple occasions. You merge, there are seemingly no conflicts, and then everything breaks.
I'd much rather repeat the same resolution over and over again and not get a bad automated resolution.


Great list, thanks so much for sharing!

I especially appreciate that your heading for rebase included the phrase before pushing - trying to rebase pushed branches and then force-pushing is such a common mistake in shared repositories, hah. Nice work!


Nice post!

git commit --amend --no-edit is a good one too.


However, git rm will remove it from both your staging area, as well as your file system, which may not be what you want.

You can use git rm --cached, which would remove file only from the staging area (the index), while leaving it on filesystem. If you don't remember the command, git status would write it down for you!

Note also that git rm --cached works any time, even after many commits -- it would always make Git no longer track the file, and no longer have it in commits / in the repository, while git reset <file> would work only after you git add-ed the file but before you have created new commit with this new file -- it simply overwrites the state in the staging area (the index) with the state from the latest commit (HEAD); thus if addition was not committed, it would untrack the file (and only then).

  1. [...] Alternatively you can enable it on a per-project basis by manually creating the directory .git/rr-cache.

What’s wrong with

git config --local rerere.enabled true

Nothing. The original post is very old though, so it (a) didn't work back then or (b) I wasn't aware of it.



perfect combination when "pull" is not working fine jojoj


Git hooks are great. I really enjoy using husky and lint-staged for a great pre-commit workflow for Node/front-end dev.


I just noticed how many commands are just mnemonic and they're not well designed. By the way, nice post!


5 can be dangerous. Just avoid doing it to already pushed code. If it's only on your local, then it's fair game IMO.

code of conduct - report abuse