Coding style checklistEstimated reading time: 2 minutes
Change and commit code
Make changes on your fork in a feature branch. Name your branch
XXXXis the issue number you are working on.
gofmt -s -w file.goon each changed file before committing your changes. Most editors have plug-ins that do this automatically.
golinton each changed file before committing your changes.
Update the documentation when creating or modifying features.
Commits that fix or close an issue should reference them in the commit message
Fixes #XXXX. Mentions help by automatically closing the issue on a merge.
After every commit, run the test suite and ensure it is passing.
Sync and rebase frequently as you code to keep up with
gitsignature and make sure you sign each commit.
Do not add yourself to the
AUTHORSfile. This file is autogenerated from the Git history.
Tests and testing
Submit unit tests for your changes.
Make use of the builtin Go test framework built.
Use existing Docker test files (
name_test.go) for inspiration.
Run the full test suite on your branch before submitting a pull request.
make docsto build the documentation and then check it locally.
Use an online grammar checker or similar to test you documentation changes for clarity, concision, and correctness.
Sync and cleanly rebase on top of Docker’s
masterwithout multiple branches mixed into the PR.
Before the pull request, squash your commits into logical units of work using
git rebase -iand
git push -f.
Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
Reference each issue in your pull request description (
Respond to pull requests reviews
Docker maintainers use LGTM (looks-good-to-me) in PR comments to indicate acceptance.
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and push additional commits to your feature branch.
Incorporate changes on your feature branch and push to your fork. This automatically updates your open pull request.
Post a comment after pushing to alert reviewers to PR changes; pushing a change does not send notifications.
A change requires LGTMs from an absolute majority maintainers of an affected component. For example, if you change
registry/code, an absolute majority of the
registry/maintainers must approve your PR.
Merges after pull requests
- After a merge, a master build is available almost immediately.