|
44 | 44 |
|
45 | 45 | 1. Go makes it very simple to ensure properly formatted code, so always run |
46 | 46 | `go fmt` on your code before committing it. You should also run |
47 | | - [golint][] over your code. As noted in the [golint readme][], it's not |
48 | | - strictly necessary that your code be completely "lint-free", but this will |
49 | | - help you find common style issues. |
| 47 | + [go vet][] over your code. this will help you find common style issues |
| 48 | + within your code and will keep styling consistent within the project. |
50 | 49 |
|
51 | 50 | 1. Any significant changes should almost always be accompanied by tests. The |
52 | 51 | project already has good test coverage, so look at some of the existing |
|
59 | 58 | * `go test github.com/google/go-github/...` |
60 | 59 | * `go vet github.com/google/go-github/...` |
61 | 60 |
|
| 61 | + The `go generate ./...` command will update or generate certain files, and the |
| 62 | + resulting changes should be included in your pull request. |
| 63 | + |
| 64 | + The `go test ./...` command will run tests inside your code. This will help you |
| 65 | + spot places where code might be faulty before committing. |
| 66 | + |
| 67 | + And finally, the `go vet ./...` command will check linting and styling over your |
| 68 | + code, keeping the project consistent formatting-wise. |
| 69 | + |
| 70 | + In any case, it is always a good idea to read [official Go documentation][] when working |
| 71 | + on this project, as the definition of tools and commands of the Go programming |
| 72 | + language is described in further detail there. |
| 73 | + |
62 | 74 | 1. Do your best to have [well-formed commit messages][] for each change. |
63 | 75 | This provides consistency throughout the project, and ensures that commit |
64 | 76 | messages are able to be formatted properly by various git tools. |
65 | 77 |
|
66 | 78 | 1. Finally, push the commits to your fork and submit a [pull request][]. |
| 79 | + Before pushing commits, it is highly advised to check for generated files |
| 80 | + that were either created or modified for the sake of your commit. Running |
| 81 | + `go generate -x ./...` should return a log of modified generated files that should |
| 82 | + be included alongside the manually written code in the commit. |
67 | 83 | **NOTE:** Please do not use force-push on PRs in this repo, as it makes |
68 | 84 | it more difficult for reviewers to see what has changed since the last |
69 | 85 | code review. |
70 | 86 |
|
| 87 | +[official Go documentation]: https://pkg.go.dev/std |
71 | 88 | [forking]: https://help.github.com/articles/fork-a-repo |
72 | | -[golint]: https://github.com/golang/lint |
73 | | -[golint readme]: https://github.com/golang/lint/blob/master/README.md |
| 89 | +[go vet]: https://pkg.go.dev/cmd/vet |
74 | 90 | [gocov]: https://github.com/axw/gocov |
75 | 91 | [gocov-html]: https://github.com/matm/gocov-html |
76 | 92 | [well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html |
@@ -128,4 +144,5 @@ this][modified-comment]. |
128 | 144 | [rebase-comment]: https://github.com/google/go-github/pull/277#issuecomment-183035491 |
129 | 145 | [modified-comment]: https://github.com/google/go-github/pull/280#issuecomment-184859046 |
130 | 146 |
|
131 | | -**When creating a release, don't forget to update the `Version` constant in `github.go`.** This is used to send the version in the `User-Agent` header to identify clients to the GitHub API. |
| 147 | +**When creating a release, don't forget to update the `Version` constant in `github.go`.** This is used to |
| 148 | +send the version in the `User-Agent` header to identify clients to the GitHub API. |
0 commit comments