What is clean history? • Production commits • Every commit has meaning • Every commit adds value • Most commits are complete features, bug fixes, or refactors
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
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
Branching protips • Always Be Branching • Use a descriptive name • Reduce longevity of branches • Clean up when you’re done • Keep changes to a minimum
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
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
feature workflow • Focused on branches for development • Master == Production • Ideal for small projects, early development • Easy to introduce to new teams
release workflow • Also called “gitflow” • Centralized around tagged releases • Ideal for larger projects, enterprise development • More complicated than feature branch workflow
release workflow Cont. • Introduces “development” and “release” branches • Branch from development branch • Merge into development branch • Merge development into release • Tag it
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
beerlington
yururoi
masatokitahara
line_developers
motok1
okunokentaro
iotengineer22
megabitsenmzq
aramaki
jacopen
nikkei_engineer_recruiting
aiji42
yamaguchitk333
eileencodes
bermonpainter
ammeep
holman
trallard
lauravandoore
cromwellryan
davidbonilla
rmw
scottboms
rocio
philhawksworth