20 comments

[ 2.8 ms ] story [ 49.2 ms ] thread
>cm = !git add -A && git commit -m

I think it's a better idea to use git add -p to review your changes before commiting them.

Alternatively, 'git commit -v' also provides a way to review the changes before you commit them. If you are not going to 'cherry-pick' the changes for the commit, this has the added benefit of showing all the whole diff at once.
I like some of these. 'wip' and 'wipe' are two operations that I regularly used. However, as I entered them into my .gitconfig I couldn't help noticing that their similarity is something that would undoubtedly bite me on the arse at some time.
It helps if you think of WIP internally always as "work in progress"

That way you're not mixing it up in your head, and wipes should be rare enough that you don't build muscle memory.

Due to autocompletion and likelihood of accidentally accepting the wrong one of either of these I renamed my wipe alias to clean.

   clean=!git add -A && git commit -m "TMP: Save before clean reset" && git reset HEAD~1 --hard
Note clean is a bad alias though as already a proper git command. I changed my alias again to ditch... :)
One alias that I find really useful is,

summary = !git log $(git log -1 --merges --pretty=format:%H)..HEAD --oneline

This prints the log summaries on one line up to the last merge commit. If you are working on a feature/topic branch (and you collaborators do too), this will just print out the commits you have add for the feature. I often use this to go back and rebase fixups or suggestions from a code review.

This is useful, but try...

git log --all --graph --pretty=format:'%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

... you get visual branching and merging, branch names, useful dates, authors, etc.

That's really cool! But there is no way I could use that at work -- our merging is a mess :D
I prefer to see some details about the files in each commit:

log --pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate --numstat

I like his idea of having an alias to commit to when he wants to save off work.

If you combine that with a checkout (co) alias which saves the current branch and checks the latest commit message of the destination branch and 'reset HEAD~1 --mixed's when it was 'SAVEPOINT' and functionally you have regular git that allows you to move around between branches without committing first.

I frequently get into a messy rebase then I hit the zipline eject button:

eject=!git reset --hard && git checkout master && git rebase --abort

Although I prefer multiple commands to be a bash or as below a fish alias:

  function giteject
    git reset --hard
    and git checkout master
    and git rebase --abort
  end
if you name the bash script "git-eject" it would still work the git command and your should get autocompletion for your command, too.
True, dotfiles aliases fixed! :)
this is awesome! thanks for this.

Although when I went to share it in slack, the preview text was "You've been Haacked and you like it". I personally find that a tasteless slogan; but more-so it should be the title of the post I linked, not the site title.

I have a few aliases in my .bashrc file that I use:

alias git-branch-list='for k in `git branch|sed s/^..//`;do echo -e `git log -1 --pretty=format:"%Cgreen%ci %Cblue%cr%Creset" "$k"`\\t"$k";done|sort'

alias c="git commit -m '"

alias s='git status'

alias a='git add'

I use the first one to hop around branches and see when the branch was last updated. The others are just because I am super lazy. But reading the post I am moved to be even lazier!

Well, it's because his name is Phil Haack ... I actually like it :)

You are right though, his title tags on his blog aren't really descriptive... Which is uncommon for a "reasonable" popular blog (Haack is almost as known as Hanselman in the .Net world, untill he left Microsoft for Github a couple of years ago - he's been more quiet since then :-) )

I added an issue for his site here: https://github.com/Haacked/haacked.com/issues/178 (gotta love developers)

> I personally find that a tasteless slogan

I'd be interested to hearing why you feel that way. Perhaps there's an angle I hadn't considered.

It's supposed to be tongue in cheek. My last name is pronounced "Hack". Being hacked is usually a bad thing. But being "Haacked" is something you would like. At least, that's my goal! :)

Is there really a reason why the common functionality should be this difficult to achieve? I don't know about you guys, but apart from the very basics, I always have to refer to a manual to complete yet another awkward command line flag. In my opinion this is like unnecessary paperwork. Don't get me wrong, I like git. It's just that it would be nice to see the core team come closer to the user, by default.
This is a more complicated version of the 2015 Fukuoka Ruby Award winner Git Reflow:

http://github.com/reenhanced/gitreflow

Do you think this is a necessary complication to Git Reflow, or think the aliases created for git workflow are worth the cognitive effort to categorize them and use them ?