Contribution Guidelines
Anything about contributing in single source code
CONTRIBUTION.md Files
Template:
Code Review
Ref:
Abbreviation:
LGTM
: Look Good To Me (approve the request)PTAL
: Please Take A Look (request for review)CL
: Change List
Git Commit
- Clear commit message
- e.g. “Fix bug” (which bug?)
- Tell what the changes and why.
- e.g. “Modify some_file.go” (What changes? Why?)
- Not too big (step by step as the thinking process)
- Not too small (focus on important change)
- “Fix typo” (Too small)
- Compile and test success
- Self-testing code
- Include the required file e.g. migration file
- No dead/commented code
- Include pairing partner (using “Coauthored By”)
Database
Ref:
TODO Comment Tag
Reference
Comment Code Tags:
NOTE:
Description of how the code worksHACK:FIXME:
/HACK
: Not very well written or malformed code to circumvent a problem/bug.XXX
/NOTE:XXX:
: Warning about possible pitfalls.FIXME
: This works, sort of, but it could be done better. (usually code written in a hurry that needs rewriting).BUG
: There is problem hereTODO
: No problem, but addtional code needs to be written, usually when you are skipping something.DOING
: Code is not completed yet
Trunk Based Development
Ref:
- trunkbaseddevelopment.com
- Paul Hammant - Branch by Abstraction
- Gordon Oheim - Trunk Based Development
- Trunk Based Development vs Git Flow
Branch by Abstraction:
- modularity through design not through git/VCS
- add an abstraction over any code you are going to change in a features
- new feature are added through Adapter and Interfaces
- production code keeps old implementation while feature is incomplete
- development code uses the new implementations
- when the feature is ready, the new implementation are rollout
Implementing feature toggle:
- feature are hidden until ready
- hide features at the entry points
- make it easy to configure
On database changes:
- must be backward compatible
- be wise on migration script so it’s easy to rollback
Good:
- lean
- can release any time
- no merge pain
Bad:
- branch no longer document features
- need feature toggle
- need to take care db changes
- need good abstraction
Do:
- Everyone commits to master at least once per day
- remote branches are only made for releases
- developer may use local branches
- hotfixes are also committed to master
- hotfixes are cherry picked into supported releases
- only Release Manager may branch release branch
Don’t: You’re doing it wrong