DEV Community

Cover image for 10 insanely useful Git commands you wish existed – and their alternatives

10 insanely useful Git commands you wish existed – and their alternatives

Eyar Zilberman on April 23, 2019

There’s a git command for that Git commands aren’t always intuitive. If they were, we would have these 10 commands at our disposal. They...
Collapse
 
mfrata profile image
Matheus Frata

Great post Eyar!!

You could have mentioned the git alias feature, in order to use these in a much more intuitive way. For instance, I have set git uncommit just like you mentioned:

  • uncommit = reset HEAD^

There are others that are useful for me:

History tree

  • tree = log --oneline --graph --decorate

Intuitive way to unstage files

  • unstage = reset HEAD --

Show the current aliases

  • alias = config --get-regexp ^alias\\.

Restore deleted file from upstream

  • restore = "!git checkout $(git upstream) -- #@"

... which depends on

  • upstream = rev-parse --abbrev-ref --symbolic-full-name @{u}
Collapse
 
eyarz profile image
Eyar Zilberman

I wanted to add information regarding the alias feature, but I was afraid it would make the post too much long for reading.

I will update the post, and I will add a link to your comment so readers will still have a reference for git alias - thanks!

Collapse
 
cameronblandford profile image
Cameron • Edited

Thanks for this great post, I learned a lot! It’s worth noting that git stash apply does the same thing as git stash pop except it’s non-destructive and doesn’t delete the stashed changes from your stash history! That way if you mess up while re-adding changes from the stash (which has happened to me before, especially during a stash merge conflict), you can easily re-implement the same stashes changes! Definitely would recommend as a preferred command.

Collapse
 
eyarz profile image
Eyar Zilberman

This is why I love the DEV community - you learn something new every day...

Thanks to you, this is what I learned today:
git stash pop is git stash apply && git stash drop. git stash pop applies the top stash and removes it, while git stash apply does the same but leaves the stash in the stack.

Therefore, it is recommended to use $ git stash apply in this use case - I will update the post :)

Collapse
 
gergelypolonkai profile image
Gergely Polonkai

Starting with #9 on a “10 things…” list? I see what you did there ☺

This is an awesome list. The only thing i find confusing is your shell prompt. I guess itʼs really useful (in colour, i assume?) but seeing it here in white on black, especially that x in place of good olʼ $ is really confusing (even though i completely understand you got rid of the dollar sign; i did, too).

Collapse
 
eyarz profile image
Eyar Zilberman

I started the list at #9 because developers have only nine fingers ;)

I first created the "terminal-feel" (with color) on my original blog post, and it looked awesome! I was sorry I wasn't able to copy the design to here, but I didn't want to use images instead of code and lose the "copy-paste" functionality...

I agree about changing the x to $, it makes more sense in black & white - so I update the terminals. Thank you for helping me make this post better! :)

Collapse
 
art4 profile image
Art4

Great post. I learned some hints. Thank you 😊

One typo in #8: It must be $ git stash pop instead of $ git pop

Collapse
 
eyarz profile image
Eyar Zilberman • Edited

Thank you for the QA :)
I fixed it here and on the original post.

Collapse
 
stecman profile image
Stephen Holdaway

It'd be worth mentioning for #5 that reverting a merge commit is something you want to avoid if possible as it creates a mess when you want to merge your branch again later.

If your merge hasn't been pushed to a shared branch yet, git reset --hard <original-branch-head> is preferable as it actually removes all trace of the merge.

From the git revert docs:

Reverting a merge commit declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in [commits introduced since the reverted merge]. This may or may not be what you want.

See the revert-a-faulty-merge How-To for more details.

Collapse
 
eyarz profile image
Eyar Zilberman

I agree, and this is also what I recommended in the git tip :)

Regarding using git reset command, you are correct, but I wanted to address the more complex scenario - when it was pushed to a shared branch.

Collapse
 
yucer profile image
yucer

The number one in my missing git command is git showtool.

I can't live without an external diff tool. We already have "git difftool" but it is very common the need to inspect which changes were added by a commit.

Collapse
 
eyarz profile image
Eyar Zilberman

+1 cool command!
This one will be added to the next article in this series ;)

Collapse
 
yucer profile image
yucer

Good idea. With the title you'd made the post attractive, and that is a motivation for the people to learn.

Nevertheless I guess that the names of those "missing comands" could be proposed according to the git naming conventions.

For example, there is already a subcommand "git branch". The missing one would be "git branch create" instead of "git create branch".

Collapse
 
eyarz profile image
Eyar Zilberman

I agree, but I tried to find the right microcopy balance between "human-friendly" VS "git oriented" commands.

I preferred to give more weight to the "human-friendly" microcopy:
For example, the command $ git undo merge is human-friendly command while the more git orientated command should be (I guess) $git merge --undo.

Collapse
 
vedgar profile image
Vedran Čačić • Edited

What have I just pulled?

git diff HEAD HEAD^1

Or something like that, I never remember. ,-]

Collapse
 
strahinjalak profile image
Strahinja Laktovic

Love the post and the way it's written, I certainly learned a thing or two, going to bookmark it. :)

Collapse
 
eyarz profile image
Eyar Zilberman

Thank you for the feedback - it's motivating me to write more content!