collaborate
• Work asynchronously
• Reduce friction in teams
• Github was built around collaboration
Slide 6
Slide 6 text
Communicate
• Poor communication causes project
failure
• Git helps reduce effort to share ideas
and build features
Slide 7
Slide 7 text
experiment
• Experimentation is part of developer
happiness
• Git encourages us to experiment via
branches
Slide 8
Slide 8 text
gain Confidence
• We need to be confident that things
will work far into the future
• Git allows us to adapt to changing
requirements
Slide 9
Slide 9 text
safety net
• We make lots of mistakes
• Git allows us to gracefully recover
Slide 10
Slide 10 text
What is code history?
Slide 11
Slide 11 text
code History
• A series of changes
• Story about how the code evolved
• Lasts forever
• Searchable
• Never outdated
Slide 12
Slide 12 text
a series of Changes
Slide 13
Slide 13 text
a series of commits
Last Commit
Slide 14
Slide 14 text
a series of commits
Slide 15
Slide 15 text
• SHA (unique identifier)
• Snapshot / Set of changes
• Description
• Date and time
• Author
• Other details (parents, etc)
What is a commit
Slide 16
Slide 16 text
fixing typos
Slide 17
Slide 17 text
refactoring code
Slide 18
Slide 18 text
documentation
Slide 19
Slide 19 text
a new feature
Slide 20
Slide 20 text
Clean history
Slide 21
Slide 21 text
recording history
Slide 22
Slide 22 text
recording history
Slide 23
Slide 23 text
why record history?
Learn from the past
Adapt to the future
Slide 24
Slide 24 text
but first a story...
Slide 25
Slide 25 text
FFFFFuuuuuuuuuu
Slide 26
Slide 26 text
What is clean history?
• Production commits
• Every commit has meaning
• Every commit adds value
• Most commits are complete features,
bug fixes, or refactors
Slide 27
Slide 27 text
reducing complexity
KISS
YAGNI
DRY
Slide 28
Slide 28 text
why clean history?
• Easier to track down why changes
were made
• Easier to track down bugs and revert
changes
• Required in some OSS projects
• Easier to backport changes
Slide 29
Slide 29 text
three types of commits
• Progress commits
• Merge commits
• Production commits
Slide 30
Slide 30 text
three types of commits
• Progress commits
• Merge commits
• Production commits
History
Not History
Slide 31
Slide 31 text
Progress commits
• Used to develop a feature
• Always in a new branch
• Track progress
• Short-term safety net
• Mutable and not permanent
• Ok if tests are failing
Slide 32
Slide 32 text
Merge commits
• Represent when a branch is merged
• Can be useful
• Not required (fast forward merges)
Slide 33
Slide 33 text
Production Commits
• Master branch
• Tagged (sometimes)
• “Immutable” and “permanent”
• These are your history
• Tests should not be failing
Slide 34
Slide 34 text
crafting a commit message
• git commit -v (verbose)
• Start with a short summary
• Follow with a description of why the
commit exists
Slide 35
Slide 35 text
short summary (<= 50 chars)
describe “why”
(72 column wrap)
Branching protips
• Always Be Branching
• Use a descriptive name
• Reduce longevity of branches
• Clean up when you’re done
• Keep changes to a minimum
Slide 45
Slide 45 text
how do i maintain clean
history with branches?
Slide 46
Slide 46 text
Rewriting history
Slide 47
Slide 47 text
ways to rewrite history
• Amending commits
• Rebasing
• Interactive Rebasing
• Resetting
Slide 48
Slide 48 text
types of rebasing
• git rebase master my_branch
• git rebase --onto master br1 br2
• git pull --rebase origin master
• git rebase -i origin/master
Slide 49
Slide 49 text
rebasing
Master
Feature Branch
Slide 50
Slide 50 text
rebasing
Master
Feature Branch
Slide 51
Slide 51 text
rebasing
Feature Branch
Master
Slide 52
Slide 52 text
Squashing Commits
Master
Squashed Commits
Slide 53
Slide 53 text
squashing commits
• Understand why you are squashing
the commits (is it a single feature, bug
fix, etc?)
• git fetch (to get master from origin)
• git rebase -i origin/master
Slide 54
Slide 54 text
git log --oneline master..convert-hashes
Slide 55
Slide 55 text
git rebase -i origin/master
Slide 56
Slide 56 text
reword & fixup
Slide 57
Slide 57 text
No content
Slide 58
Slide 58 text
No content
Slide 59
Slide 59 text
After Before
git log --oneline master..convert-hashes
Slide 60
Slide 60 text
rebasing protips
• Always fetch before rebasing
• Never rebase a branch someone has
based work off
• Prolong squashing as long as possible
• Don’t be discouraged
Slide 61
Slide 61 text
isn’t that dangerous?
Slide 62
Slide 62 text
how does it all fit
together?
Slide 63
Slide 63 text
My workflows
• Years of changing workflows
• Started centralized (subversion style)
• Evolved to feature and release focus
Slide 64
Slide 64 text
general workflow
• Create branch
• Write code and commit it
• Open pull request (code review)
• Squash commits (if needed)
• Merge & tag
• Ship it™
Slide 65
Slide 65 text
two types of workflows
• Feature branch centric
• Release centric
Slide 66
Slide 66 text
feature workflow
• Focused on branches for development
• Master == Production
• Ideal for small projects, early
development
• Easy to introduce to new teams
Slide 67
Slide 67 text
feature workflow cont.
•Branch from master
• Write code
• Open pull request (code review)
•Merge to master
• Test in staging environment
• Ship it™
Slide 68
Slide 68 text
feature workflow cont.
Master
Slide 69
Slide 69 text
feature workflow cont.
Master
Feature Branch
Slide 70
Slide 70 text
feature workflow cont.
Master
Feature Branch
Slide 71
Slide 71 text
feature workflow cont.
Master
Slide 72
Slide 72 text
release workflow
• Also called “gitflow”
• Centralized around tagged releases
• Ideal for larger projects, enterprise
development
• More complicated than feature branch
workflow
Slide 73
Slide 73 text
release workflow Cont.
• Introduces “development” and
“release” branches
• Branch from development branch
• Merge into development branch
• Merge development into release
• Tag it
Slide 74
Slide 74 text
release workflow cont.
courtesy atlassian.com
Slide 75
Slide 75 text
clean history workflow
• Every merge/tag has meaning
• Every merge/tag adds value
• All merges/tags are complete
features, bug fixes, or refactors
Slide 76
Slide 76 text
what can we do with a
clean history?
Slide 77
Slide 77 text
Search commits
Slide 78
Slide 78 text
Search by message
git log -p --grep "wtf"
Slide 79
Slide 79 text
Search by message
Slide 80
Slide 80 text
search by content
git log -p -S 'wtf'
Slide 81
Slide 81 text
search by author
git log -p --author='beerlington'
Slide 82
Slide 82 text
search by author
Slide 83
Slide 83 text
Search by date
git log -p --since=2013-01-01
git log -p --until=2013-09-01
or...
Combine them!
Slide 84
Slide 84 text
track down bugs
Slide 85
Slide 85 text
git bisect
Broken
X
Slide 86
Slide 86 text
git bisect
Bad
Good
✓ X
Slide 87
Slide 87 text
git bisect
Bad
Good
? X
✓
Slide 88
Slide 88 text
git bisect
Bad
Good
X
✓
Slide 89
Slide 89 text
git bisect
Bad
Good
X
✓ ?
Slide 90
Slide 90 text
git bisect
Bad
Good
X
✓ X
Slide 91
Slide 91 text
git bisect
X
X
✓ ✓
✓
✓ ✓
Slide 92
Slide 92 text
git bisect
• Determine how to verify the bug
• Find commit before bug was
introduced
• Find commit after bug was introduced
• git bisect
Slide 93
Slide 93 text
git bisect
Slide 94
Slide 94 text
git bisect
Slide 95
Slide 95 text
git bisect
Slide 96
Slide 96 text
git bisect
Slide 97
Slide 97 text
git bisect protips
• Automate with “run” option
• The cleaner the history, the easier and
faster it is to bisect
• git bisect visualize can show where
you are in the process