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
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+2-46Lines changed: 2 additions & 46 deletions
Original file line number
Diff line number
Diff line change
@@ -20,50 +20,6 @@ If you want to make a change to the inotify-rs code, please open a pull request
20
20
21
21
If you're having any problems with completing your change, feel free to open a pull request anyway and ask any questions there. We're happy to help with getting changes across the finish line.
22
22
23
-
## Commit guidelines
24
23
25
-
We use [clog] to generate a changelog for each release. This is done automatically, using the commit messages as a data source. Therefore it is very important to write clear commit messages and tag them in a way that the tool can understand.
26
-
27
-
The rest of this section explains the rules for commit messages. Please don't be put off, if this seems overwhelming. As always, if you're unsure about anything, just send a pull request. [GitCop] and the reviewer will happily point out any problems.
28
-
29
-
Before we go into the rules, here's an example of a commit message:
30
-
```
31
-
feat: Implement a feature
32
-
33
-
This is the commit message body. It is optional and might consist of
34
-
multiple paragraphs.
35
-
36
-
Here's the message body's second paragraph. The next paragraph is going
37
-
to automatically close an issue, once the commit is merged into the
38
-
repository.
39
-
40
-
Closes #123456.
41
-
```
42
-
43
-
First, let's start with the first line, the header. It's the most important part of the commit, as it's used by [clog] to generate the changelog. For that reason, it's the most heavily regulated part:
44
-
- The header's purpose is to concisely summarize the changes made.
45
-
- It must be **at most 50 characters** long.
46
-
- It should be written in the **imperative voice**, as if you're commanding someone. So, "Add something", as opposed to "Adding something" or "Added something".
47
-
- It must begin with the type of commit, followed by a colon (e.g. "feat:" or "fix:"). The following types can be used:
48
-
-**feat**: New functionality, or changes (not bug fixes) to existing functionality.
49
-
-**fix**: Bug fixes
50
-
-**docs**: Improvements to documentation
51
-
-**style**: Code formatting, indentation, etc.
52
-
-**refactor**: Changes to code that don't change what it does. Cleaning up, moving stuff around, etc.
53
-
-**perf**: Performance improvements
54
-
-**test**: Changes to test code
55
-
-**chore**: Custodial work that isn't directly related to the code. Changes to the build system, etc.
56
-
57
-
These rules apply to the message body:
58
-
- The messages body is optional, but should be added if the header and the commit diff by themselves don't explain why the commit is necessary.
59
-
- It should **provide context** for the commit and **explain its reasoning**. It doesn't need to restate things that are already obvious from the commit diff.
60
-
- Please be mindful of explanations of how the code works. Often, it makes more sense to add such explanations to the code itself, as comments.
61
-
- The length limit for lines in the commit body is **72 characters**.
62
-
- If any issues should be closed once the commit is merged, this can be done automatically by adding something like "Closes #123456" to the commit. Be careful about not doing this accidentally.
63
-
64
-
That's it! If anything about this document is unclear, feel free to open an issue. If you have questions regarding a pull request that you're working on, just open the pull request and ask your questions there.
0 commit comments