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...
For further actions, you may consider blocking this person and/or reporting abuse
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:
reset HEAD^There are others that are useful for me:
History tree
log --oneline --graph --decorateIntuitive way to unstage files
reset HEAD --Show the current aliases
config --get-regexp ^alias\\.Restore deleted file from upstream
"!git checkout $(git upstream) -- #@"... which depends on
rev-parse --abbrev-ref --symbolic-full-name @{u}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!Thanks for this great post, I learned a lot! It’s worth noting that
git stash applydoes the same thing asgit stash popexcept 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.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 popisgit 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 applyin this use case - I will update the post :)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
xin place of good olʼ$is really confusing (even though i completely understand you got rid of the dollar sign; i did, too).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
xto$, it makes more sense in black & white - so I update the terminals. Thank you for helping me make this post better! :)Great post. I learned some hints. Thank you 😊
One typo in #8: It must be
$ git stash popinstead of$ git popThank you for the QA :)
I fixed it here and on the original post.
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 revertdocs:I agree, and this is also what I recommended in the git tip :)
Regarding using
git resetcommand, you are correct, but I wanted to address the more complex scenario - when it was pushed to a shared branch.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.
+1 cool command!
This one will be added to the next article in this series ;)
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".
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 mergeis human-friendly command while the more git orientated command should be (I guess)$git merge --undo.What have I just pulled?
Or something like that, I never remember. ,-]
Love the post and the way it's written, I certainly learned a thing or two, going to bookmark it. :)
Thank you for the feedback - it's motivating me to write more content!