Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Here are my thoughts... all these will be open to interpretation depending on your particular development methodologies.</p> <ul> <li>You should be committing fairly often, with a single focus for every commit, so based on that, comments should be short and detail what the focus of the commit was.</li> <li>I'm a fan of posting the <em>what</em> in your comment, with the <em>why</em> and the <em>how</em> being detailed elsewhere (ideally in your bug tracking). The why should be the ticket, and upon closing the ticket, you should have some kind of note about how that particular issue was addressed.</li> <li>A reference to your bug tracking system is good if it isn't handled otherwise (TRAC/SVN interaction, for example). The reason for this is to point other developers in the right direction if they're looking for more information on the commit.</li> <li>Don't include specific file names unless the fix really complex and detail is needed. Even still, complex details probably belong in bug tracking with your implementation notes, not in version control. Files edited, diff details, etc, should hopefully be included with version control, and we don't want to spend time duplicating this.</li> </ul> <p>Given these ideas, an example commit comment for me would be something like</p> <blockquote> <p>Req3845: Updated validation to use the new RegEx validation developed in Req3831.</p> </blockquote> <p>Short, communicates what was changed, and provides some kind of reference for others to get more info without hunting you down.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload