Commits and Pull Requests Guide

pr-checklist.md

Some more explanation below

Checklist Commit messages

• The first line of a commit message must complete the following sentence: This commit will ...
• Describe the functional change so it is clear why we need it.
• The first line must start with a capital and it must not end with a period.
• Describe the why and how of a commit in the rest of the message. The what can be read from the code changes.
• The length of the first line is preferred to be 50 or less characters.
• Every line must contain no more than 72 characters.
• The second line must be empty.
• Do not add tags to the first line.
• Add the JIRA issue to the last line of the commit message if applicable.

Checklist Commits and code-style

• CS Fixes to existing code must be in a separate commit.
• Use php-cs-fixer (with level symfony) before committing new files.
• For existing files, that do not conform to our CS standards, do not cs-fix the old code.
• Every commit should contain a single functional change.
• Rebase any bugfix and/or typo commits for bugs that are introduced in the current branch.

Checklist Pull requests

• The title of the pull request must complete the following sentence: This pull request will ...
• Prefix the JIRA issue to the pull request if applicable.
• Only submit pull requests with code that is stable enough to move to staging/production.

pr-guide.md

Commit messages

1. The first line of a commit message must complete the following sentence: This commit will ...
2. The first line must describe the functional change so it is clear why we need it.
3. The first line must start with a capital and it must not end with a period.
4. Describe the why and how of a commit in the rest of the message. The what can be read from the code changes.
5. The length of the first line is preferred to be 50 or less characters.
6. Every line must contain no more than 72 characters.
7. The second line must be empty.
8. Do not add tags to the first line.
9. Add the JIRA issue to the last line of the commit message if applicable.

Example of an acceptable commit message

Stop adding initial server to server list by default

The initial server is not necessary to be writable, because it just acts
as a routing layer. It may not even *be* writable in the first place. In
fact, it may not even have access to anything else.

Therefore only add it as a writable server when there are none listed.
We need to do so because of backwards compatibility.

Part of: CMD-1234

What are "tags"?

Tags are the stuff you prefix to a sentence in a commit message. Examples of previously used tags: New, Bugfix, Major.

Commits and code-style

1. CS Fixes to existing code must be in a separate commit.
2. Use php-cs-fixer (with level symfony) before committing new files.
3. For existing files, that do not conform to our CS standards, do not cs-fix the old code.
4. Every commit should contain a single functional change.
5. Rebase any bugfix and/or typo commits for bugs that are introduced in the current branch.

Enforcing php-cs-fixer on commit

The php-cs-fixer can be executed automatically for example by using: https://github.com/reenl/dotfiles

Skip the automatic php-cs-fix check by using git commit -n.

Pull requests

1. The title of the pull request must complete the following sentence: This pull request will ...
2. Prefix the JIRA issue to the pull request if applicable.
3. Only submit pull requests with code that is stable enough to move to staging/production.

Ready?

Yeah I got this!