DEV Community

10 Git Tricks to Save Your Time and Sanity

Jacob Herrington (he/him) on August 07, 2019

1. Checkout a single file from another branch Have you ever destroyed a file and just wished you could have a fresh start? Or needed the...

Read full post

Forest Hoffman • Aug 8 '19

Nice post Jacob!

4. Get rid of all untracked changes

I also like to use git reset --hard HEAD.

5. Print out a cool visualization of your log

My fav git aliases that are always in my ~/.gitconfig:

[alias]
    lg1=log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all
    lg2=log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all
    lg=!git lg1

Jacob Herrington (he/him) • Aug 8 '19

Thanks for sharing!

Christopher Keele • Aug 10 '19

Love this, incorporating some of them into my git tricks!

Building on your alias list command, I have an alias called alias:

alias.alias !alias(){ git config --get-regexp "^alias.${1}"; }; alias

This'll list all aliases matching the provided prefix, or just all aliases with no arguments:

git alias
# ... many lines of cool aliases
git alias alias
# alias.alias !alias(){ git config --get-regexp "^alias.${1}"; }; alias
git alias ancestor
# alias.ancestor merge-base --octopus
git alias c
# alias.current rev-parse --abbrev-ref HEAD
# alias.contains !contains(){ git fetch && git rev-parse ${1:-HEAD} | xargs git branch -r --contains; }; contains
# alias.cherrypick cherry-pick

Robert Myers • Aug 11 '19

git commit -v --amend

Do not do this if you've already pushed that commit. If a push ever requires --force, you need to think long and hard about whether or not it's something you should do.

One thing that I use a lot on Windows is Posh-git. It places branch, commit and index status in the command prompt

Thomas H Jones II • Aug 8 '19

A few weeks ago, I used #9 to figure out "how long has this feature been in our code before someone made a complaint about it."

Specifically, we do build-automation. Someone requested we include tool in the resultant builds. I'd looked at the system the person was complaining didn't have the component, only to find that it was present ...just that the associated run-time service wasn't activated. Ultimately, found that the tool had been in the build for nearly four years in this "installed but not automatically started" state. Was able to tell the requestor, "good news: the tool has been in place four nearly four years; I just had to update the automation to ensure that it actually starts on boot. The only remediation you need for old systems is to enable the service rather than having to figure out how to deploy and install it."

...All this because the maker of the tool had a botch in their installer that caused the enablement to not actually happen. :p

Jacob Herrington (he/him) • Aug 9 '19

Stories like this are the reason I think it makes sense to learn git at a deeper level than branch, add, commit, repeat.

Thomas H Jones II • Aug 9 '19

True, but that could be said for many (most?) tools. That said, a lot of people never have reason to use those advanced features (and, on the rare occasion that they do, if their Google-Fu is half-decent, they'll find what they need that way).

Austin S. Hemmelgarn • Aug 10 '19 • Edited

Two other big ones come to mind that I often see underutilized, but find indispensable on a regular basis:

Interactively stage individual parts of files for a commit

Sometimes, you end up fixing bugs in nearby code that you didn't notice until you were testing something else. Or maybe you end up needing to split out a big bunch of changes into separate logical steps. Or perhaps you just forgot to commit something before starting on the next thing.

In any case, you can use:

git add -i

It will bring up a menu-based interface to step through individual hunks of the current set of changes to the working tree and let you select only the parts you want to include in the commit.

Rearrange (or completely rewrite) the history of a branch

git rebase also has an interactive mode (also enabled with the -i switch). You can use this to edit history back to a certain commit without moving the branch you're on by running:

git rebase -i <commit>

The commit you specify should be the last one before the commit you want to start editing things at. Just like a normal rebase, you can specify a tag or a branch name instead of a commit here (or use a commit-like form like HEAD~8). This will open an editor with a list of instructions to git for how to perform the rebase (it defaults to what it would do if you were doing a regular rebase), as well as some comments below that explaining what each instruction means.

Things you can do with this include:

Change the order of commits. Just reorder them in the list that shows up when you start the interactive rebase.
Completely remove commits from history. Just remove the lines for those commits from the list, or change the pick at the beginning of the lines to drop.
Insert completely new commits. Add a break to the list where you want to put the new commit, the rebase will stop there and drop to a shell, where you can make your code changes and commit them just like normal, then run git rebase --continue to resume the rebase. You can also use this to merge branches or cherry pick commits into arbitrary locations in your history.
Amend commits arbitrarily far back in the history. Replace pick with edit, the commit will be applied, but the rebase will stop immediately afterwards so you can use git commit --amend to update the commit. This is essentially a shorter form of adding a break after the commit.
Squash commits. Put the line for the commit you want to squash right after the one you want to squash it into, then replace the pick with squash.
Meld fixes into the commit they fix. Same as squashing, just use fixup instead of squash and it will just use the commit message from the first commit as-is instead of prompting you to enter a new one for the single commit it produces.
Split commits. Mark the commit you want to split to be amended, then run git reset HEAD~ when the rebase stops to let you amend that commit. This will remove that commit from the history, but leave all the changes it made to the working tree in place, and you can then split them out into new commits however you want (possibly using git add -i to simplify the process).
Verify the code state between commits. You can add a line starting with exec wherever you want in the sequence of commands. The rebase process will pass the rest of that line to the shell to be run as a command (essentially, it calls sh -c followed by the rest of the line) at that point during the rebase, and will stop the rebase if the command fails (just like if a merge failed) so that you can investigate what happened and either cancel the rebase or continue it as you see fit.

edmistond • Aug 10 '19

Nice list! I've been using git consistently for five or six years now and still learn new stuff about it all the time.

Related to #5, this is probably my single most used git alias and quite possibly the most-used CLI command on my system:

[alias]
    lg = log --color --graph --decorate --pretty=format:'%C(bold cyan)%h%Creset -%C(bold red)%d%Creset %s %C(bold green)(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

I have it zsh aliased to 'ggd' so I can quickly check the history of my current branch and whether certain other branches are in the history (basically seeing at what point I last rebased on master, or if I need to again).

Adam Crockett 🌀 • Aug 7 '19

Emergency servival kit: ohshitgit.com/

Jacob Herrington (he/him) • Aug 7 '19

That's awesome.

Always an option:

cd ..
sudo rm -r fucking-git-repo-dir
git clone https://some.github.url/fucking-git-repo-dir.git
cd fucking-git-repo-dir

Christopher Keele • Aug 10 '19

Or just:

rm -rf .git
git init .
git remote add origin https://some.github.url/fucking-git-repo-dir.git
git fetch

To avoid moving out of the directory, overwriting it, or losing changes

The Half Blood Prince • Aug 9 '19

For #8, you can simply type

git alias

to list all the configured aliases for you.

Jacob Herrington (he/him) • Aug 9 '19 • Edited

Hmm. Are you sure that's not a plugin or something? It doesn't seem to work for me.

EDIT: Found it! github.com/tj/git-extras/blob/mast...

The Half Blood Prince • Aug 13 '19

Oh yes! This plugin has integrated so seamlessly with my flow that I almost forgot I had it installed.

Vaibhav Namburi • Aug 8 '19

git reflog is an absolute saviour for me too!

Raul Robinson Quispe Mendez • Oct 4 '19 • Edited

I'm disappointed 😞 to not see here one of my favorite git commands

git worktree add <path-to> <branch-name>

ref 👉 git-scm.com/docs/git-worktree

rhymes • Aug 8 '19

This is great!

Nathan Grass • Aug 8 '19

What is the purpose of -- in the first command? Seems an unnecessary argument.

Jacob Herrington (he/him) • Aug 8 '19

It is kind of superfluous. It is just a more formal way to indicate that you are specifying the file name. I included it here in case someone took the example and made an alias out of it.

Imagine you had a file called master and you wanted to check that file out, git checkout master would probably do something different than you wanted, but git checkout -- master would check that file out from the current branch.

Jesse Phillips • Aug 9 '19

It signifies the end of command options. It is useful with transferring control to sub commands. In D you can provide compiler options then pass arguments to the compiled program.