github.com/zntrio/harp/v2@v2.0.9/CONTRIBUTING.md (about) 1 # How to contribute 2 3 This document outlines some of the conventions on development workflow, commit 4 message formatting, contact points and other resources to make it easier to get 5 your contribution accepted. 6 7 ## Getting started 8 9 - Fork the repository on GitHub. 10 - Read the README.md for build instructions. 11 - Play with the project, submit bugs, submit patches! 12 13 ## Contribution flow 14 15 This is a rough outline of what a contributor's workflow looks like: 16 17 - Create a topic branch from where you want to base your work. This is usually master. 18 - Make commits of logical units and add test case if the change fixes a bug or 19 adds new functionality. 20 - Run tests and make sure all the tests are passed. 21 - Make sure your commit messages are in the proper format (see below). 22 - Push your changes to a topic branch in your fork of the repository. 23 - Submit a pull request to the repo. 24 25 Thanks for your contributions! 26 27 ## Coding Style 28 29 The coding style suggested by the Golang community is used in this repository. See the 30 [style doc](https://github.com/golang/go/wiki/CodeReviewComments) for details. 31 32 ## Commit message guidelines 33 34 ### Structure of the commit message 35 36 ```text 37 <type>(optional scope): <description> 38 39 optional body 40 41 optional footer 42 ``` 43 44 ### **Type** 45 46 - **fix**: The commit represents a bug fix for the bridge components 47 - **feat**: The commit represents a new feature for the bridge components 48 - **doc**: The commit represents a change in the documentation 49 - **chore**: Other changes 50 51 The type **fix** and **feat** will be added to changelog and version will be bumped. 52 53 > Please note that using `BREAKING CHANGE:` will bump the `major` version. 54 55 ### **Optional scope** 56 57 - `fix` and `feat` use the name of command. Example: `fix(vctx): <description>` 58 - `doc`: try to use name of command. Example: `doc(harp): <description>` 59 - `chore`: readme, build scripts, dependencies, .. 60 61 ### **Description** 62 63 The description contains succinct description of the change: 64 65 - use the imperative, present tense: "change" not "changed" nor "changes" 66 - don't capitalize first letter 67 - no dot (.) at the end 68 69 ### **Optional body** 70 71 Just as in the subject, use the imperative, present tense: "change" not "changed" 72 nor "changes". The body should include the motivation for the change and contrast 73 this with previous behavior. This can also reference issues. 74 75 ### **Optional footer** 76 77 All breaking changes have to be mentioned in the footer. You can also reference issues. 78 79 ## Examples 80 81 ```text 82 feat(harp): add virtual filesystem 83 84 implementd using Afero library 85 86 close #149 87 ``` 88 89 ```text 90 chore: add contributing guidelines 91 ```