Atomic Commits
Keep your codebase healthy
without acting like the thought police
Barun Singh
Founder/CTO
Boston Ruby Group, 11 Dec 2012
Slide 2
Slide 2 text
A Social Anarchist View
of Software Development
Slide 3
Slide 3 text
Our objectives
Reliable application
Maintainable code
Scalable process
Knowledgeable team
Slide 4
Slide 4 text
Let’s take this one step at a time
Testing
Code reviews
Communication
Slide 5
Slide 5 text
Your team’s process ought to:
protect the codebase
Slide 6
Slide 6 text
TDD
“Write tests first.
Watch them fail.
then write code”
Slide 7
Slide 7 text
Guiding principle:
Your process ought not
tell you how you must think
Slide 8
Slide 8 text
4PNFUJNFT
ZPVKVTUXBOUUP
HPFYQMPSJOH
Slide 9
Slide 9 text
Laws ought to
protect the commons, but
preserve individual liberty
Slide 10
Slide 10 text
Laws ought to
protect the commons, but
preserve individual liberty
codebase
developer flexibility
Your team’s process
Slide 11
Slide 11 text
Your team’s process ought to:
protect the codebase
preserve developer flexibility
Slide 12
Slide 12 text
Your team’s process ought to:
protect the codebase
preserve developer flexibility
encourage clear communication
Slide 13
Slide 13 text
Convey intention across space and time.
Slide 14
Slide 14 text
Your team’s process ought to:
protect the codebase
preserve developer flexibility
encourage clear communication
foster learning
Slide 15
Slide 15 text
“If I had to do this again,
maybe I could find an easier path.”
Slide 16
Slide 16 text
Your team’s process ought to:
protect the codebase
preserve developer flexibility
encourage clear communication
foster learning
Slide 17
Slide 17 text
Git Branching Strategy
master is always deployed
All changes are mage on branches that are merged
master
in-progress
feature
Slide 18
Slide 18 text
master is the commons Feature branches are
where you get your work done
Slide 19
Slide 19 text
Do whatever you want on your branch,
but follow group norms for master
And what if I don’t?
Nothing, we just won’t accept your pull request.
Slide 20
Slide 20 text
Rules of the commons
1. Every commit must make sense on its own
2. Every commit must do something meaningful
3. No commit may break the build
4. Every commit must include thorough tests for all code changes
Every commit must be atomic
Slide 21
Slide 21 text
Why?
1. Every commit must make sense on its own
Communication and clarity
2. Every commit must do something meaningful
Less noise == less frustration
3. No commit may break the build
Reliability (part I)
4. Every commit must include unit & acceptance specs for all code changes
Reliability (part II)
Slide 22
Slide 22 text
The final process
Formulate an
approach
Write your
code & tests
Organize your
branch
Present code
for review
Iterate based
on feedback
QA & merge
into master