The almighty Oh Shit, Git!?! has all the answer when you have, once again, fucked things up with git.

Use tig for visual workflows. Or magit.

Learn from this game Oh My Git!.

Retrieve older versions of a file

git reflog <file>
git checkout <commit-id> -- <file>

Fetch & Merge Upstream into Fork

git remote add upstream
git fetch upstream
git merge upstream/main
git push

Deleting Commits

# Letzten Commit im aktuellen Branch löschen
git reset --hard HEAD~1
# Spezifischen Commit löschen
git reset --hard <sha1-commit-id>
# Danach muss 1x so gepusht werden:
git push origin HEAD --force

Reverting Commits

git revert <commit>

You should really only use reset if the commit being reset only exists locally. This command changes the commit history and it might overwrite history that remote team members depend on.

revert instead creates a new commit that undoes the changes, so if the commit to revert has already been pushed to a shared repository, it is best to use revert as it doesn’t overwrite commit history.

With ssh superpowers

git clone through ssh - Stack Overflow


Move current uncommitted changes to new branch

git switch -c <branch>


Git - Einfaches Branching und Merging


Git with large files - Stack Overflow

Error Messages

What if I want a local-only .gitignore?

Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file. – gitignore#_description

nano .git/info/exclude


git remote set-url origin
# Replace origin with whatever