The document discusses best practices for source control including committing code frequently, writing detailed commit messages, and following a good development process of getting up-to-date, building, testing locally, and committing changes. Anti-patterns for commit messages like vague messages without details are also highlighted.

1. WHA T’ s the
P RO B L E MS ？

2. 2 S tories……

3. S to ry
N O .1

4. Releas New Release
e Feature ??

5. S to ry
N O .2

6. svn
repository
libs

8. The only measure of progress is working
code in source control.

9. If it’s not in source control,
it doesn’t exist...

10. Get up-to-date before working on a file.

11. Do not commit if code doesn’t pass local
testing or won’t even compile.

12. Immediately commit after completing a
piece of functionality.

13. Every committed revision gives you a
rollback position.

14. The risk of a merge nightmare increases
dramatically with time.

15. It forces you to isolate features into
discrete units of work.

16. One commit for one purpose.
One purpose into one commit.

17. Do not commit any artifacts auto-
generated out of the building process(e.g.
program binary).

18. Make sure all commit contain comments.

21. Here are some anti-patterns of good commit messages:
1. Some shit.
2. It works!
3. fix some fucking errors
4. fix
5. Fixed a little bug...
6. Updated
7. typo
8. Revision 1024!!

25. Good process:
1. Get up-to-date
2. Build
3. Never work on broken build
4. Develop
5. Build
6. Local testing
7. Commit
8. Resolve conflicts immediately
9. Get up-to-date