...
The description of a github Pull Request will be used as the message for the merge commit for the branch so all PR descriptions should follow these rules.
All PR descriptions/commit messages should have a title AND a body. Just repeat the title for the body if you can't think of anything to add.
The title should completely describe the change within its character limits. e.g. Do "Add new evaporation scheme", "Fix convection bug". Do not continue the sentence in to the body.
The first sentence of the body should be passive and not contain a subject. It is understood you are talking about the commit or PR. Do not start with "This commit...." or "This PR...". Just start with "Add" or "Fix" or "Change".
Keep the body brief. Just a few sentences. For PRs, use the comments after the description to add more detail if you want.
Do not substitute github issue numbers for descriptions of what you are fixing or doing. "Fixes #999" is not a good commit message. Imagine that GitHub goes away someday. The log messages in our git repo should still make sense. Reference issue numbers at the end (the "FIxesFixes" lines) or parenthetically.
In addition to JIRA issue numbers at the bottom of the commit, you may, but are not required to, use other commands to manipulate the associated JIRA issue. See JIRA and Github linking.
Do not include URL's to Confluence or other web sites. For PR's, use the first comment after the description to add URL's or more detail.
Commit message in a branch
| Code Block |
|---|
Describe changes in less than 70 characters in title.
Be sure to add a blank between title above and this text. In the body of the message provide more detail on what these changes do.
It should be enough information for someone not following this development to understand. DO NOT LEAVE THE BODY BLANK. Just repeat the title if you have to.
[BFB] or [non-BFB] or [CC] !! Add at least ONE of these keys to indicate how this commit will affect testing against baselines.
!! [BFB] means all output from tests will be [BFB] with the baselines.
!! [non-BFB] one more more tests will not be BFB with baselines. You can specify the tests. You can also
!! use [non-BFB] and follow it with a description of what cases will be non-bfb if those arent under test.
!! [CC] the commit will change the climate of one or more cases under test.
[FCC] !! Add [FCC] if the commit will change climate if a flag is activated.
[NML] !! Add [NML] if the commit introduces changes to the namelist.
AG-67, AG-56 !! On the last line, add JIRA issue numbers for issues this commit is satisfying if available. |
Merge commit messages (For Integrators when merging to "next" OR "master")
| Code Block |
|---|
Merge branch <branchname> (PR #10) !! Add the PR # to the automatically generated title. Leave "into next" in title when merging to next.
!! Don't worry about going over the 70 char limit.
(Be sure to add a blank after above title)
(copy and paste the original description from the PR. It may already have the content below.)
(copy and paste the testing description in the PR and add info on any more testing done prior to merging)
Fixes #XY, Fixes #MN (For commit to master only, include Github issue numbers for the bugs this commit fixes. Be sure to use the word "Fixes"
before each # to close the associated bugs)
[BFB] or [non-BFB] or [CC] !! Add ONE of these keys to indicate if this commit will affect testing results to roundoff [non-BFB]
!! or climate changing [CC]. Use [BFB] if-and-only-f commit is bit-for-bit and
!! you know all the tests will pass without regenerating baselines.
[FCC] !! Add [FCC] if the commit will change climate if a flag is activated.
[NML] !! Add [NML] if the commit introduces changes to the namelist.
LG-92 (if there are also JIRA issue numbers, add those below github issues and BFB keys.)
(If the merge produces merge conflicts,the list of files that were in conflict should be left in the message.)
|
...