Stefan Bauer
Developer and Creator of PingPing.io, a simple website monitoring.
Blog Building PingPing Newsletter About

These git aliases make my daily work faster and easier

Published on August 16, 2017

My personal approach has changed during the last years over and over again. However, meanwhile I always use the same aliases. In this post I assume that you know what aliases are and how they are used. I will show you some really cool things which are possible with aliases.

In case you don’t know how to add aliases, you can add all the examples below in the [alias] section in your git configuration file. In most cases this is a .gitconfig in your home directory.

Pro-Tip: With git alias a list of all your configured git aliases is shown. For the people who can’t remember all the aliases they set up.

You have also to use this global configuration, that you get the wonderful formatting in the history I have. This should also go in your .gitconfig.

[pretty]
    changelog = format:* %h %s
    pretty-history = format:%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset

For anyone who doesn’t know how this works:

You can specify different and custom “prettys” in your .gitconfig. In your git log command you can then specify them within an option like pretty=<your-custom-pretty>. Cool, hm? You will see it several times in the tips below.

Anyways... let’s get started!

1. Always being up to date

I will start with the first command, which is not a real git alias. But i still use it a lot. I really never use git pull or so. It’s called git up. You can find it here: https://github.com/aanand/git-up

It fetches all locally tracked remote branches and rebases them. Really helpful! So with the command git up all branches are up to date!

2. The every-day basic aliases

These are the absolut standard abbreviations that i use. Nothing special. I just want to include them here, because I use them a lot. A lot more then git up.

st = status
ci = commit

co = checkout
co-staged = !git diff-index --cached --name-only --diff-filter=ACMR HEAD | xargs git co

di = diff
staged = diff --cache
di-staged = !git diff-index --cached --name-only --diff-filter=ACMR HEAD | xargs git di

dilc = diff --cached HEAD^

fa = fetch --all -v
ff = pull --ff-only
rv = remote -v

pt = push --tags origin master:master develop:develop

Here is a very quick explanation of some of them, because i think most of them should be clear and are nothing special.

  • git co and git co-staged are quite the same. The only difference is, that git co-staged checks the files out, that have the state in the staging area. Quick Example: Add a file to the staging area (State A), modify the same file (State B). If you are unhappy with the result, you can restore State A (from the staging area) with this git co-staged.
  • git di and git staged are also quite the same. But guess what, the only difference is, that git staged shows only the diff from the files in the staging area. In both cases it shows the diff to your working tree.
  • git di-staged is really cool. It is similar to git staged but the difference is, that it shows the diff between the staging area and your modified files.
  • git dilc gives you the diff between your working tree and the last commit.
  • git fa fetches all remote but be verbose
  • git ff applies the changes from remote only when it would be possible via fast forward
  • git rv shows remote information with a verbose level (for instance url and such information)
  • git pt pushes all tags on master and develop. This is what I use, when I finished a release or hotfix in the known git flow.

3. History and Browsing

Here are some aliases I use regularly for browsing repositories

3.1 Change-Log

This is something I use, when i copy and paste it as kind of a Change-Log into some README files or send it via mail.

cl = log --pretty=changelog --no-merges --cherry --abbrev-commit --date-order

3.2 Pretty History

This is something I use the whole day. With that i get a very quick detailed overview about the history.

ph = log --graph --pretty=pretty-history --abbrev-commit --date=relative

3.3 Pretty Detailed History

I often use this alias because it gives me some more details about the some details in the history, that the very quick pretty history does not give.

pdh = log --pretty=pretty-history --decorate --numstat

3.4 File Log

When you would like to see the history of a single file, you can use the file log alias.

fl = log -u

You have to append the file you are interested in.

3.5 Stat Log

If you are interested in some stats, you can use this one. I use it not very often, but from time to time it’s useful.

sl = log --oneline --reverse --no-merges --stat

If you don’t provide a range, you get will get it from the very first commit. Otherwise you have to provide a range like:

git sl ca30f3b6..b6e302e2

4. Adding files to the staging area

What you do the whole day, is to add files or hunks to the staging area. Here are some easy and quick tips how you can improve your workflow. I’m going to show you how i do it.

4.1 Files that are already tracked

With this only files that are already tracked by git will be added to the staging area.

update = add -u

What i use also often is a small modification of the above, like

git update -p

What this does, is the same as git update, so adding files to the staging area that are already tracked, but the difference is, that you get asked for each file which portion you would like to add.

Git tries its best to separate the different parts. You can choose then if you would like to

  • (y) accept it
  • (a) accept it and accept all other hunks in this file
  • (n) discard it
  • (d) discard it and discard all other hunks in this file
  • (s) split it into smaller hunks
  • (e) edit it
  • (j) leave undecided and jump to next
  • (k), leave undecided and jump to previous

4.2 Only files in the staging area

Sometimes I am only interested in adding files to the staging area, that are modified and which are already in the staging area. Sounds confusing? It does, but it helps a lot. For instance I use it very often in combination with my coding standards. Before applying coding standards I add a file to the staging area, after that I run git cs-staged, then i have a file in the staging area (without cs-fixes) and a modified file (with cs-fixes). Then this command comes in and add only these files, which are already in the staging area and are modified also.

I do not want to add these files blindly. Therefore I add it via -p so i can decide which hunk i would commit and which one not.

up-staged = !f() { git ls-staged; }; git add -p `f`

If you are updating/adding not the whole file (for instance if you are not satisfied with some cs-fixes) you can then bring the staging area and your local working tree to the same state with git co-staged.

5. Merging

When you merge some branches and there come up some conflicts and you don’t want to resolve the conflicts manually, you can choose which modification you would like to apply. Here we go.

5.1 Using our changes

ours = "!f() { git co --ours $@ && git add $@; }; f"

5.2 Using their changes

theirs = "!f() { git co --theirs $@ && git add $@; }; f"

6. Listing Tags

You are interested in some tags? Here we go.

6.1 Getting the last tag/latest version

In case you are using git flow as me, this alias is one i use a lot, before creating new versions or so.

lt = describe --tags --abbrev=0

What you get is something like this:

git lt
v3.11.0

7. Applying Coding Standards

Personally I always apply the defined coding standards with the php-cs-fixer before pushing to remote. This is my workflow I am used to to. This alias is one, you need that the others are working. Don’t forget, that you need a global installed php-cs-fixer to get this working and ideally a configuration file that fit your needs in each project you are using it.

coding-standards = !php-cs-fixer fix

7.1 Applying to given file(s)

cs = !f() { git diff-tree --no-commit-id --name-only --diff-filter=ACMR -r "$1" | xargs -n1 git coding-standards; }; f

This alias is available to uniformity, but I do not use it very often. What i really use is the one below git cs-staged.

7.2 Applying to all files in the staging area (before pushing)

cs-staged = !git diff-index --cached --name-only --diff-filter=ACMR HEAD | xargs -n1 git coding-standards

If you have enjoyed my posts or you like what I'am talking/twittering about, you should signup. I will show you everything i know about development and UI/UX.

Imprint Cookie Policy Privacy Policy
Proudly hosted with Vultr