Readers/Web/Team/Engineering conventions/Commit summary guidelines
Commits are important as they give the reviewer more information to successfully review your code and find errors or potential problems you might not have thought of.
Commits are also useful when troubleshooting issues and refactoring. If it's not clear why a line of code is in the repository important bug fixes could be lost.
Commits should be as minor as possible. Please avoid removing unrelated changes (e.g fixing unrelated whitespace). Instead do that in a separate commit/
First line commit should summarise the commit with bug it fixes if applicable. e.g. *Fix problem with toggling see bug x*. Second line should be blank. Third line should go into detail where necessary providing links to blog posts/other bugs to provide more background. Mention the platforms/browsers the change is for where necessary, e.g.:
- *This is a problem on Android but not OSX, see `http://<url></url>` which explains problem in detail*
- *This is a workaround for a known bug in opera mobile see `http://<url></url>`*
Commit summary guidelines for MobileFrontend
[edit]- Follow Git/Commit message guidelines
- Don't forget to state phabricator task at the end of the commit.
- If the commit depends on another commit to external repository (such as MediaWiki core) in a way relevant to WMF deployment, state it clearly using Depends-On field. This will ensure the patch doesn't get merged before it should do.
- If it is not obvious how to test your commit (eg you have to do magic things to your set up in order to test), explain it in the commit message and/or task.
Commit summary syntax (in discussion)
[edit]For bugfixes:
Do something and everything works Optional detailed info Depends-On: Change-Id Bug: T233 Change-Id: xxx