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
  • actually it completely replaces previous commit with a new one

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
Made with Slides.com