DEV Community

Turn around your Git mistakes in 17 ways

Smitter on October 09, 2022

Mistakes! These are not a necessity in software development. But they always find a way to taint the beauty of software development. Let's make pe...

Read full post

FJones • Oct 9 '22

For 17 I would instead almost always recommend making a new commit on HEAD and then using rebase with the fixup verb to reorder and join the commits. This is for the simple reasons that it:

creates a reflog entry
lines up with the rebase workflow
has some safeguards for timeline-incompatible changes (i.e. file existed at the time but had entirely different contents)

Similarly, I would avoid the restore command, instead using checkout and reset where appropriate.

Valentin Nechayev • Oct 11 '22

creates a reflog entry

Really, a reflog entry appears for each state at begin and end of each rebase, so they at least can be recovered.

has some safeguards for timeline-incompatible changes (i.e. file existed at the time but had entirely different contents)

That's why, an opposite, a file could be easily edited with the edited commit but not later.

Similarly, I would avoid the restore command, instead using checkout and reset where appropriate.

restore is a new command which just unifies multiple use cases for former checkout, branch and reset under a convenient common name. It hasn't added new functionality. To use restore or older variants is still just a matter of taste.

Smitter • Oct 9 '22

Well I think it is a bit of work having to reorder the commits so as to use the fixup action verb.

Then regarding the restore command, it was built for the restoring purpose in mind unlike the checkout command which is like a know it all command

Lucas Perez • Oct 10 '22

Just as a side note, if you need to reorder and then fixup, you can instead just squash and then rewrite the commit message appropriately. Squash itself puts you in a commit "screen" anyways, so you can easily use the commit message you want.

Valentin Nechayev • Oct 11 '22 • Edited

A good intro, just a few notes:

For commands like restore, it is useful to separate paths from options with '--', e.g. git restore -s <commit_id> -- <path1> <path2>. Shell completion relies on it.

For recipe 3, if not to add -m, this opens editor. In a case of multiline commit message (typical for a complex project) this is much handier.

Recipe 9: it's useful to note exceptions to cleaning, like: git clean -dfx -e .vscode.

For recipe 11: git log works with commit ids as well, so, git log -p <id> may suggest what was the branch to restore. Anyway, well, good messages are useful... but I'm regularly encountering the same commit sequence over different branches.

Smitter • Oct 13 '22

Good notes👍. For recipe 9, I am curious why would I add the -x and then manually add -e. Looks like a lot of work

Valentin Nechayev • Oct 13 '22 • Edited

I am curious why would I add the -x and then manually add -e.

This is the case build artifacts (all of them - object files, libraries, autogenerated sources, etc.) are present in the same directory as the working copy. Normally, they are all in .gitignore. Heavy cleaning from build results require deleting all of them. But, if IDE and other locals aren't a level upper, they are to be saved from deletion.

Robin Bastiaan • Oct 12 '22 • Edited

Good overview of the different options at your disposal! Thank you very much for the article.

I just want to add that not all methods will remove your data from the repository. In normal circumstances that is exactly what you want. However, if you accidentally committed a password for example, this is something to look out for. In that situation it can make sence to revert your commit by rewriting history, but this will only make sence if you have not yet commited your code to the remote repo. If that is the case, you are better off considering your password compromised and start changing your password.

Smitter • Oct 13 '22

Changing your password is a good security precaution at personal level. I agree👍.

Jesse Phillips • Oct 13 '22

I have some added suggestions to complement what you have.

Use git switch instead of git checkout.

Rather than just dropping changes with a reset, switch into a new branch, commit, then switch out. This ensures if nothing else you'll have a reflog for a bit.

$ git commit --fixup

Or search a commit message instead of hash

$ git commit --fixup :/msg