User Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
en:devel:commitguidelines [2015/03/01 17:10]
joebordes
en:devel:commitguidelines [2019/04/23 00:00] (current)
joebordes
Line 3: Line 3:
 [[https://​docs.google.com/​document/​d/​1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/​mobilebasic?​pli=1|AngularJS Git Commit Message Conventions]] [[https://​docs.google.com/​document/​d/​1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/​mobilebasic?​pli=1|AngularJS Git Commit Message Conventions]]
  
-<​code><​type>​(<​scope>​)<​subject></​code>​ +<​code><​type>​(<​scope>​) <​subject></​code>​ 
-  * Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on github ​as well as in various git tools.+ 
 +another way of reading that is: 
 + 
 +<​code>​what(where) how</​code>​ 
 + 
 +in this second form, the //when// and //who// are controlled by git itself, so sign your commits. 
 + 
 +Some additional clarifications:​ 
 + 
 +  * Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub ​as well as in various git tools.
   * Allowed **<​type>​**   * Allowed **<​type>​**
-    * **feat** ​(feature) +    * **feat**feature 
-    * **fix** ​(bug fix) +    * **adapt**: this is a feature, but it only affects a particular install, not the whole coreBOS project 
-    * **i18n** ​(translation strings and enhancements) +    * **fix**bug fix 
-    * **docs** ​(documentation) +    * **security** 
-    * **style** ​(formatting, missing semi colons, …) +    * **i18n**translation strings and enhancements 
-    * **refactor** +    * **docs**documentation 
-    * **test** ​(when adding missing tests) +    * **style**formatting, missing semi colons, … 
-    * **chore** ​(maintain)+    * **refactor**: code refactor 
 +    * **test**when adding missing tests 
 +    * **chore**: maintenance tasks
   * Allowed **<​scope>​** could be anything specifying place of the commit change. For example a module name, webservice or functional feature   * Allowed **<​scope>​** could be anything specifying place of the commit change. For example a module name, webservice or functional feature
-  * **<​subject>​** line contains succinct description of the change. Use imperative, present tense: “change” not “changed” nor “changes”. If the commit fixes or is related to a ticket ​we will put the mantisbt regular expression here+  * **<​subject>​** line contains succinct description of the change. Use imperative, present tense: “change” not “changed” nor “changes”. 
 +    * If the commit fixes or is related to a ticket put the title or a summary of it, the actual ticket number is rather useless as time has taught me that ticket systems come and go while code and commit messages persist.