Code should be submitted with a reasonable suite of tests, and code should be designed with testability in mind.
Commit messages should explain why code is changing, configuration is added, or new types or packages are introduced. Prefer a declarative style, like
Pass a quit channel to allow canceling goroutines
All code needs code review and at least one "thumbs up" from a colleague. After the thumbs up the person who submitted the merge/pull request should click the merge button. Always choose "delete branch" when merging to keep the number of old branches low on the server.
Code should be submitted as a single squashed commit via a merge/pull request. Only open a request with fully designed and tested solution that you would be comfortable merging. PRs are not for designing solutions, that's what issues are for.
If code requires special local testing, provide a test plan in a PR comment (not the commit message or merge request description). Step by step instructions or a script are ideal.
Overall, you should strive to make reviewing efficient for your colleagues.
The changelog is a valuable resource. It is maintained in CHANGELOG.md. Most PRs should include edits to the changelog to describe bug fixes, API changes, or new features added.
Use these prefixes when editing the changelog.
- FIX - If this change contains a bugfix or security fix to an existing feature.
- NEW - Implementation of a new feature or API operation.
- Enhancement - Existing feature is altered with new functionality or significantly changed.
- Refactor - No material changes to interfaces or business logic. General code cleanup.
Functions should take as few parameters as possible. If many parameters are required, consider introducing a new type that logically groups the data.
Large blocks of commented out code should not be checked in.
Avoid the use of global variables. Prefer a dependency injection style that uses a mix of interfaces and concrete types.
All work should be documented in issues and collected into a milestone or sprint. Sprints map to two-week periods of time. At the beginning of a sprint, we discuss work we want to do and make sure all of it is documented in issues. Bugs and hot fixes can be added to the middle of the sprint, but not without discussion.
To create a release, do the following:
- Pick a version number for the release. Our example below is 0.1.0
- Add that version number as a header in CHANGELOG.md and write a description of what's changed there. MR that update to CHANGELOG.md to develop branch.
- When the MR of changes is accepted, one team member does the following from the command line:
git fetch origin
git checkout master
git reset --hard origin/develop
git tag -a v0.1.0 -m 'version 0.1.0'
git push origin --tags
If you ever need to delete a tag, you can do this:
git tag -d v1.0.4
git push origin :refs/tags/v1.0.4
This is 💯% great!