git-hero

From git-zero to

Michał Urbanek

Git as we know it

• clone
• branch
• add
• commit
• pull

• push
• log
• checkout
• merge
• ...

Environment

PS1='\[\e[0;33m\]\u\[\e[0m\]@\[\e[0;32m\]\h\[\e[0m\]:
     \[\e[0;34m\]\w\[\e[0;31m\]$(git_prompt)\[\e[0m\]\$ '

git_prompt ()
{
    if ! git rev-parse --git-dir > /dev/null 2>&1; then
        return 0
    fi

    git_branch=$(git branch 2>/dev/null| sed -n '/^\*/s/^\* //p')
    echo " [$git_branch]"
}

# git completion
source ~/.git-completion.bash

git commit --amend

• fix up the most recent commit
• combine staged changes with previous commit
• simply edit previous commit message

merge  vs  rebase

• they both solve the same problem
• integrate changes from one branch to another
• they just do it in very different ways

git merge

• easier to understand
• creates a new "merge" commit
• non-destructive
• easy to revert
• log might be confusing

    git merge master feature

git rebase

• moves entire "feature" branch to begin on the tip of the master branch 
• rewrites/simplifies project history
• creates brand new commits for each commit in original branch

    git checkout feature
    git rebase master

git pull --rebase

• by default pull performs merge
• this way it will rather perform rebase
• this behaviour can be set to default

rebase pros

• much cleaner project history
• no merge commits
• perfectly linear history - no forks
• easier to navigate with git bisect, git log, gitk

The dark side of rebase

The dark side of rebase

• loses context of workflow
• potentially catastrophic for collaboration workflow

The golden rule of rebase

• Is anyone else looking at this branch?
• YES - take your hands off the keyboard. NOW!
• NO - just do it!

Interactive rebase

    git checkout feature
    git rebase -i master

• more powerful then automated rebase
• offers full control over branche's history
• clean up messy history before merge
• like git commit --amend on steroids
• split, reorder, remove, alter existing commits

Rule of thumb

• use pull --rebase
• DO rebase small local branches
• do NOT rebase long living branches on which you collaborate with others
• in such case it's better to do an explicit merge --no-ff

Trust this guy

People can (and probably should) rebase their _private_ trees (their own work). That's a _cleanup_.

But never other peoples code. That's a "destroy history".

Linus Torvalds

Aliases

  git config --global alias.co checkout
  git config --global alias.br branch
  git config --global alias.ci commit
  git config --global alias.st status
  git config --global alias.visual "!gitk"

• no need to type long commands
• shortcuts for most frequent commands
• create commands that you think should exist
• run external commands with !

References

• https://www.atlassian.com/git/tutorials/rewriting-history
• https://www.atlassian.com/git/tutorials/merging-vs-rebasing
• http://git-scm.com/book/en/v2/Git-Branching-Rebasing
• https://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/
• http://nathanleclaire.com/blog/2014/09/14/dont-be-scared-of-git-rebase/
• http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
• https://github.com/jakubnabrdalik/gitkurwa