Make changes on your fork in a feature branch. Name your branch
XXXX is the issue number you are working on.
gofmt -s -w file.go on each changed file before
committing your changes. Most editors have plug-ins that do this automatically.
golint on 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
Closes #XXXX or
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
git signature and make sure you sign each commit.
Do not add yourself to the
AUTHORS file. This file is autogenerated from the
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 docs to 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
master without multiple branches
mixed into the PR.
Before the pull request, squash your commits into logical units of work using
git rebase -i and
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 (
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
an absolute majority of the
docs/ and the
registry/ maintainers must
approve your PR.