Intro

• What we'll cover
  • collaboration with others
  • more advanced error recovery
  • bug forensics

Credits

• Thank you, SCCC, thank you SeaGL, and thank you all the sponsors!

It's a Mystery!

• Something's broken. Grab your Sherlock hat and pipe.
• git bisect (demo repo)
  • binary search for commit introducing bug
• other helpful tools
• git blame
• continuous integration
  1. use blame to see who changed the offending line, and when
  2. CI would have found the bug right after it was committed

Collaboratification

• You've identified and fixed a problem. Now, get your fix upstream!

Get familiar with GitHub

• GitHub at a glance
  • very popular, integrates with everything
  • lightning-fast collaboration
  • proprietary, but most data+history are in git
  • if you can use Git, you can use GitHub

Central repo "workplace" example

• GitHub pull request demo
  • create branch
  • commit change
  • push change
  • create PR
  • merge PR
  • delete branch

$ git checkout -b newtitle
$ editor README.md
$ git commit
$ git push -u origin newtitle

Spread the fix around

• Cherry picking
  • diff-and-apply from anywhere to anywhere
  • consider -x, as in git cherry-pick -x COMMIT
    1. commit something to a branch
    2. cherry-pick it onto another branch
• Merging, conflict resolution
  • software (including Git) doesn't help much
  • great communication does!

Get Clever (1/3)

• We've spent weeks on this change. Meanwhile, upstream has marched on!
• time to integrate locally: git merge or git rebase
  • either works: it's a matter of preference
  • let's rebase

Aside: rebase vs. merge

Get Clever (1.5/3)

• practical rebasing
  • git rebase --interactive
  • git pull --rebase
  • git config branch.autosetupmerge always
    1. Make a series of commits on a branch, some fixups, etc..
    2. Make more nonconflicting changes on master

    $ git rebase -i HEAD^^^
    

    $ git rebase master
    

• never rebase a shared branch!

Get Clever (2/3)

• interactive commit
  • just like add -p followed by commit
    Make some local modifications, then

    $ git commit --interactive
    

• git reflog
  • recover lost commits

    # make changes
    $ git commit -m 'first'
    # make more changes
    $ git commit -m 'second'
    # whoops! blow away 'second'
    $ git reset --hard HEAD^
    # hooray, git still has it
    $ git reflog
    $ git reset --hard HEAD@{1}
    

    Note that git merge HEAD@{1} also works. Good luck with that one.

    Further reading:

    1. http://gitready.com/intermediate/2009/02/09/reflog-your-safety-net.html
    2. http://gitready.com/advanced/2009/01/17/restoring-lost-commits.html

• git stash
• like a cheapy cheap branch
  Make some local modifications, then

  $ git stash
  # or
  $ git stash save 'WIP almost cracked SHA-512'
  $ git stash list
  $ git stash show -p
  $ git stash pop
  # or
  $ git stash drop
  

Get Clever (3/3)

• git grep
  • can grep working tree or other treeishs
• git show
  • See content from history or other branches

Get Old School (1/2)

• Creating patches by hand
  • format-patch
  • git diff
  • git send-email
  • git request-pull

    Here we will do some of the same things that we did with github, only we will do them manually to show a bit more of what's going on, and to give you an idea of how to operate outside of GitHub.

    Create some more changes but don't commit.

    $ git diff > foo.patch
    

    Now commit it (and more) and then use format-patch to get the patch(es)

    $ git format-patch HEAD^
    $ git format-patch <hash>^
    

    Finally show how you can send email directly with many options

    $ git send-email --compose --to jkeating@j2solutions.net --subject "Stuff" HEAD^^
    

    Git request-pull allows you to create a summary of differences in your fork of a project. Very similar to a GitHub pull-request.

    $ git request-pull origin/master jlk ansible
    

Get Old School (2/2)

• Applying patches
  • git apply
  • git am
  • signed-off-by
  • format-patch / am is better because context

    Here is how we can process the patch set. This is also what GitHub is doing, and again we'll see the details of what happens.

    Applying someting created with (git) diff is git apply.

    Applying something created with git format-patch is git am

    signed-off-by can be used to add a layer of record keeping

    format-patch is better as it includes more context than pure diff

Further reading

• Fork this talk: https://github.com/meonkeys/git-talk
• Read Pro Git! Now. Do it now.

• set core.autocrlf appropriately!
• git reference manual (man pages)
• git-enhanced shell prompt and tab-completion
  • invaluable info included in prompt
• Adam's Git config
• Interactive revert, hand-edited commits