Define 'logical unit of work'

Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
This commit is contained in:
Arnaud Porterie 2015-03-16 09:30:32 -07:00
parent e2ca237aa2
commit 68a9cd63cc
1 changed files with 12 additions and 4 deletions

View File

@ -217,10 +217,18 @@ mixed into the PR.
feature branch to update your pull request rather than `merge master`.
Before you make a pull request, squash your commits into logical units of work
using `git rebase -i` and `git push -f`. After every commit, [make sure the test
suite passes]((https://docs.docker.com/project/test-and-docs/)). Include
documentation changes in the same pull request so that a revert would remove all
traces of the feature or fix.
using `git rebase -i` and `git push -f`. A logical unit of work is a consistent
set of patches that should be reviewed together: for example, upgrading the
version of a vendored dependency and taking advantage of its now available new
feature constitute two separate units of work. Implementing a new function and
calling it in another file constitute a single logical unit of work. The very
high majory of submissions should have a single commit, so if in doubt: squash
down to one.
After every commit, [make sure the test suite passes]
((https://docs.docker.com/project/test-and-docs/)). Include documentation
changes in the same pull request so that a revert would remove all traces of
the feature or fix.
Include an issue reference like `Closes #XXXX` or `Fixes #XXXX` in commits that
close an issue. Including references automatically closes the issue on a merge.