Atomic Commits

Keep your codebase healthy without acting like the thought police.

Presenting a process for collaborative software development that yields high quality code, preserves developer flexibility, and fosters communication and learning.

1. Atomic Commits Keep your codebase healthy without acting like the thought police Barun Singh Founder/CTO Boston Ruby Group, 11 Dec 2012
2. A Social Anarchist View of Software Development
3. Our objectives Reliable application Maintainable code Scalable process Knowledgeable team
4. Let’s take this one step at a time Testing Code reviews Communication
5. Your team’s process ought to: protect the codebase
6. TDD “Write tests first. Watch them fail. then write code”
7. Guiding principle: Your process ought not tell you how you must think
8. 4PNFUJNFT ZPV
   KVTU
   XBOU
   UP
   HP
   FYQMPSJOH
9. Laws ought to protect the commons, but preserve individual liberty
10. Laws ought to protect the commons, but preserve individual liberty codebase developer flexibility Your team’s process
11. Your team’s process ought to: protect the codebase preserve developer flexibility
12. Your team’s process ought to: protect the codebase preserve developer flexibility encourage clear communication
13. Convey intention across space and time.
14. Your team’s process ought to: protect the codebase preserve developer flexibility encourage clear communication foster learning
15. “If I had to do this again, maybe I could find an easier path.”
16. Your team’s process ought to: protect the codebase preserve developer flexibility encourage clear communication foster learning
17. Git Branching Strategy master is always deployed All changes are mage on branches that are merged master in-progress feature
18. master is the commons Feature branches are where you get your work done
19. 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.
20. 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
21. 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)
22. 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
23. Thank you. bsingh@wegowise.com