I agree. The commit log is a very important way to trace the issues the bugs. We should obey the Chris Beam's Golden rules, STRICTLY.
-- 此致！Best Regards 陈明雨 Mingyu Chen Email: morning...@163.com; morningman....@gmail.com At 2018-10-31 15:38:06, "Zhao Chun" <buaa.zh...@gmail.com> wrote: >Hi all, > >I want to discuss Apache Doris(incubating) code commit specification. > >Pull requests. In order to ensure that our master branch is working, we >will disable the contributor push code master branch directly. >On GitHub we will open `Require pull request reviews before merging` for >master, so the code must be merged into the master branch after someone >else's review. > >2. Versions. Apache Doris(incubating) will use the 3-digit version for >future release, [Major.Minor.Patch]. > >3. Branches. In the Apache Doris(incubating) repository, there are two >types of branches, one is the master branch, the other is the release >branch. >code and issue will go to master branch, and release branch is used to fix >bug of release. >The naming convention for the release branch is branch-x.y. For example, >when we release the 0.9 version, we will make a branch called branch-0.9. >The released version is 0.9.0. > >4. Commit Messages. We are going to follow Chris Beam's Golden rules for >Commit Message. Here is the golden rules >a. Separate subject from body with a blank line >b. Limit the subject line to 50 characters >c. Capitalize the subject line >d. Do not end the subject line with a period >e. Use the imperative mood in the subject line >f. Wrap the body at 72 characters >g. Use the body to explain what and why vs. how >The full post link is here <https://chris.beams.io/posts/git-commit/>, and >explain why. > >5. Commits. Every contributor should as much as possible to plan >their commits, and try to split a large commit into multiple small commits. >This will make it easier for others to review and understand the content of >the code. > >Need your reply > >Thanks, >Zhao Chun
