From 68a9cd63cc4ca3c898388fe814a2dd8b7fca385e Mon Sep 17 00:00:00 2001 From: Arnaud Porterie Date: Mon, 16 Mar 2015 09:30:32 -0700 Subject: [PATCH] Define 'logical unit of work' Signed-off-by: Arnaud Porterie --- CONTRIBUTING.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index da1bf2b494e21..39fe0fe4fc807 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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.