Then should we use the "[SSHD-xxx:related]" prefix (otherwise someone might think that the issue is what the text says - and it isn't)...
-----Original Message----- From: Guillaume Nodet [mailto:[email protected]] Sent: Thursday, May 7, 2015 09:30 To: Lyor Goldstein; [email protected] Subject: Re: Question regarding "intermediate" commits of "collateral" changes Ccing dev@ ... 2015-05-07 7:39 GMT+02:00 Lyor Goldstein <[email protected]>: > Hi Guillaume, > > > > I wanted to consult you about your opinion on the following scenario: > a developer is working on a feature/bug, and during this work some > changes are made to the code that are useful regardless of the actual > feature/bug – e.g., add some new generic utility, make some other code more > robust, etc.. > – let’s call it a “collateral” change. My question is how to reflect > this situation in the commit log ? > > > > I thought of the following options (please feel free to suggest more): > > > > 1. Create a *new* JIRA issue for the collateral changes and > performs 2 commits – one for the collateral change and the other for > the feature/bug > > > > My reluctance to recommend this option is that a JIRA issue should be > used > (IMO) for “big” things – major features, bugs, etc.. The collateral > change is an *incidental* by-product of the main JIRA issue. Sometimes > it might be something as little as adding a new 3-lines generic method. > > > > 2. Perform 1 commit that contains * both* the collateral change and > the “main” feature > > > > My reluctance to use this option is that if the main feature is rolled > back, then so is the useful collateral code. Furthermore, other code > may have been built on top of the collateral code and it would break. > In other words, my view is that commits should be as *restricted* in > scope as possible so that if they are rolled back, it minimizes the > chances of breaking some other code > > > > 3. Still perform 2 commits, but use a *naming convention* on the > commit for the collateral code – e.g. “*[SSHD-XXX:related] Did X, Y, Z*” > > > > My personal favorite is this one since it combines the linear history > of the commit log, the restricted scope of the commits and still > conveys enough information – the log message describes the collateral > change, but indicates that it was triggered by the work on a JIRA > issue. We should discuss the naming convention to adopt (if you agree with > me). > > > > What is your opinion ? > #3 is the best imho. All commits should have [SSHD-xxx] at the beginning of the commit message, but eventually very trivial changes (though they will most certainly not appear in the change log). I think it's totally fine to split a work on a single JIRA with several commits. Guillaume > Lyor >
