- This is not religious or philosophy, but art and practice.
- Pursuit rationality and mental health.
- You can apply this to both company projects and your own private project because who u r today is different from who is yesterday.
- Simple and clear, the 1st line is a summary of the commit:
- In other words, a single commit must be summarizable.
- Explains "Why is the change necessary, what for?"
- You can avoid extra communication through code review.
- Keeps approprate commit size:
- Avoid a large amount of code changes in a single commit. (it depends)
- Easy to look through the commit for reviewers
- Independent:
- Each commit can be reverted one by one
- However, it depends on the situation.
- "Commit log should be activity logs."
- Why? Who decides it?
- "Added XXX model" explains nothing. This is explicit when you see the code changes.
- If activity logs are used for your evaluation, you should leave that circumstance.
- "It's anti-historical revisionism (to arrange the commit logs/messages.)"
- This is not ideology.
featurebranches are just working branches, and you can revise them until you're satisfied with. (Of coursegit push -f origin masteris never acceptable.)
- "I never review the code per commit, but per GitHub's pull-request"
- You're locked in the service.
- After merged, do you always find the pull-request when you find what happened past?
- "The most important thing is delivering the product to customers (and so we don't always need to write good commit messages.)"
- Of course, delivering a product to users is important. BUT you can also write GOOD commit messages. Both can be achievable.