@@ -263,21 +263,30 @@ and for each pull request there may be several commits. In particular:
263
263
264
264
Commit messages should follow the following structure::
265
265
266
- bpo-42: the spam module is now more spammy (GH-NNNN)
266
+ bpo-42: Make the spam module more spammy (GH-NNNN)
267
267
268
268
The spam module sporadically came up short on spam. This change
269
269
raises the amount of spam in the module by making it more spammy.
270
270
271
271
The first line or sentence is meant to be a dense, to-the-point explanation
272
- of what the purpose of the commit is. If this is not enough detail for a
273
- commit, a new paragraph(s) can be added to explain in proper depth what has
274
- happened (detail should be good enough that a core developer reading the
275
- commit message understands the justification for the change).
272
+ of what the purpose of the commit is. The imperative form (used in the example
273
+ above) is strongly preferred to a descriptive form such as 'the spam module is
274
+ now more spammy'. Use ``git log --oneline `` to see existing title lines.
275
+ Furthermore, the first line should not end in a period.
276
+
277
+ If this is not enough detail for a commit, a new paragraph(s) can be added
278
+ to explain in proper depth what has happened (detail should be good enough
279
+ that a core developer reading the commit message understands the
280
+ justification for the change).
276
281
277
282
Check :ref: `the git bootcamp <accepting-and-merging-a-pr >` for further
278
283
instructions on how the commit message should look like when merging a pull
279
284
request.
280
285
286
+ .. note ::
287
+ `How to Write a Git Commit Message <https://chris.beams.io/posts/git-commit/ >`_
288
+ is a nice article that describes how to write a good commit message.
289
+
281
290
282
291
.. _cla :
283
292
0 commit comments