You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Modify the git commit guide to be clearer, specifically asking to link
GitHub issues with every commit. Also update the pull request template
with the line "Fixes #issue-number" so that every PR will close an issue
when it is merged.
@@ -31,41 +32,45 @@ To run the test suite simply run `npm test` (after installing dependencies with
31
32
32
33
A sample unit test could be found here: [Nav.test.jsx](../client/components/__test__/Nav.test.jsx).
33
34
34
-
## Writing Git Commit Messages
35
+
## Committing Code
36
+
Inspired by [Git/GitHub commit standards & conventions](https://gist.github.com/digitaljhelms/3761873).
35
37
36
38
Good commit messages serve at least three important purposes:
37
39
38
40
* They speed up the reviewing process.
39
41
* They help us write good release notes.
40
42
* They help future maintainers understand your change and the reasons behind it.
41
43
44
+
45
+
### General Rules
46
+
* Make [atomic commits](http://en.wikipedia.org/wiki/Atomic_commit) of changes, even across multiple files, in logical units. That is, as much as possible, each commit should be focused on one specific purpose.
47
+
* As much as possible, make sure a commit does not contain unnecessary whitespace changes. This can be checked as follows:
48
+
49
+
```
50
+
$ git diff --check
51
+
```
52
+
53
+
### Commit Messages
54
+
42
55
Structure your commit message like this:
43
56
44
57
```
45
-
Short (50 chars or less) summary of changes ( involving Fixes #Issue-number keyword )
58
+
[#issueid] Short (50 chars or less) summary of changes
46
59
47
-
More detailed explanatory text, if necessary. Wrap it to about 72
48
-
characters or so. In some contexts, the first line is treated as the
49
-
subject of an email and the rest of the text as the body. The blank
50
-
line separating the summary from the body is critical (unless you omit
51
-
the body entirely); tools like rebase can get confused if you run the
52
-
two together.
60
+
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
53
61
54
62
Further paragraphs come after blank lines.
55
63
56
64
- Bullet points are okay, too
57
65
58
-
- Typically a hyphen or asterisk is used for the bullet, preceded by a
59
-
single space, with blank lines in between, but conventions vary here
66
+
- Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
60
67
```
61
-
62
68
* Write the summary line and description of what you have done in the imperative mode, that is as if you were commanding someone. Start the line with "Fix", "Add", "Change" instead of "Fixed", "Added", "Changed".
69
+
* Link the GitHub issue you are working on in the summary line in brackets, e.g. [#123]
63
70
* Always leave the second line blank.
64
71
* Be as descriptive as possible in the description. It helps reasoning about the intention of commits and gives more context about why changes happened.
65
-
66
-
### Tips
67
-
68
72
* If it seems difficult to summarize what your commit does, it may be because it includes several logical changes or bug fixes, and are better split up into several commits using `git add -p`.
73
+
* Note that you can connect multiple issues to a commit, if necessary: `[#123][#456] Add Button component`
69
74
70
75
## Design
71
76
-[Style Guide/Design System on Figma](https://github.com/processing/p5.js-web-editor/labels/good%20medium%20issues)
0 commit comments