docs: add branch naming conventions
License: MIT Signed-off-by: Jeromy <why@ipfs.io>
Jeromy committed
Aug 3, 2016 at 09:28 UTC
cf04b1f38ed81d243f687ddaf90051929622024d
1 file changed
+17
contribute.md
+17
@@ -28,6 +28,23 @@ All commits in a PR must pass tests. If they don't, fix the commits and/or [squa
28
29
We use CI tests which run when you push to your branch. To run the tests locally, you can run any of these: `make build`, `make install`, `make test`, `go test ./...`, depending on what youre looking to do. Generally `go test ./...` is your best bet.
30
31
+### Branch Names
32
+
33
+If you are working on a new feature, prefix your branch name with `feat/`. If you are fixing an issue, `fix/`. If you are simply adding tests, `test/`. If you are adding documentation, `doc/`. If your changeset doesn't fall into one of these categories, use your best judgement and come up with your own short prefix.
34
+
35
+After that, try to signal what part of the codebase this branch is working on. For example, if you are adding a new test to the DHT that tests for nil providers being returned, then `test/dht/nil-provs` would be acceptable. If your changes don't fall cleanly in a single module, you can use a more general descriptor, or leave it off in favor of a slightly more wordy description.
36
+
37
+Please also try to keep branch names around or under 20 characters. It keeps things a little cleaner overall. Also try to avoid putting issue numbers in branch names, it takes up space without providing any immediately relevant context about the changeset.
38
+
39
+A few examples of good branch names:
40
+
41
+- `feat/cmds/object-diff`
42
+ - For a Pull Request that adds an `ipfs object diff` command.
43
+- `test/dag/cache-invalid`
44
+ - For adding tests around the merkledag's cache invalidation code.
45
+- `doc/unixfs/pkg-desc`
46
+ - For a branch that adds or improves the package description in unixfs.
47
+
48
### Commit messages
49
50
Commit messages must start with a short subject line, followed by an optional,