User:8680/GitGoodPractice - Revision history

8680: /* Commits */

2014-03-16T06:42:29Z

‎Commits

8680: /* Commit messages */

2014-03-14T02:08:38Z

‎Commit messages

8680 at 01:38, 14 March 2014

2014-03-14T01:38:02Z

8680: /* Commits */

2014-03-14T01:30:00Z

‎Commits

8680: /* Commit messages */

2014-03-14T01:28:50Z

‎Commit messages

8680: /* Commits */

2014-03-14T01:27:40Z

‎Commits

8680: /* Commits */

2014-03-14T01:26:41Z

‎Commits

8680: Created page with "== Commits == * A commit should be, to quote shadowm, “sufficiently self-contained that it can be reverted and reapplied as many times as you want without leaving any relate..."

2014-03-02T06:39:40Z

Created page with "== Commits == * A commit should be, to quote shadowm, “sufficiently self-contained that it can be reverted and reapplied as many times as you want without leaving any relate..."

New page

== Commits ==
* A commit should be, to quote shadowm, “sufficiently self-contained that it can be reverted and reapplied as many times as you want without leaving any related changes behind”.
** A commit to a long-running (or otherwise non-topic) branch should not be intended to require subsequent commits to function.

== Commit messages ==
* A commit message consists of a summary line and a message body, which must be separated with a blank line.
* The message body should describe and explain the changes made in the commit as fully as possible.
** The message body should be hard-wrapped to 72 characters (or 72 columns; some characters can occupy multiple columns).
* The summary line should summarize the message body in such a way as to be most useful for developers reviewing the commit history in the future.
** The summary line should be written in “imperative present tense”.
** The summary line should be a sentence, written without a full-stop character at the end.
** The summary line should be limited to 50 characters or less.
*** shadowm professed to prefer an 80-character limit, but later clarified that that preference is not to be taken as policy.

== Pull requests ==
* A pull request should always request the pull of a topic branch, never a long-running branch (like a ‘master’ branch).
* A pull request should be self-contained, like a commit should be.

@@ Line 2: / Line 2: @@
 * A commit should be, to quote shadowm, “sufficiently <strong>self-contained</strong> that it can be reverted […] without leaving any related changes behind”.
 ** A commit to a long-running (or otherwise non-topic) branch should <strong>work on its own</strong>, without requiring subsequent commits.
-*** It’s fine for a commit to not work (or only partially work) if it’s a commit to a temporary topic branch, which is to be merged into (<em><strong>not</strong></em> rebased onto) another branch when the commit series achieves full functionality.
+*** It’s fine for a commit to not work (or only partially work) if it’s a commit to a temporary topic branch, which is to be merged into (<em><strong>not</strong></em> fast-forward-merged into, or rebased onto) another branch when the commit series achieves full functionality.
 == Commit messages ==

@@ Line 1: / Line 1: @@
 == Commits ==
-* A commit should be, to quote shadowm, “sufficiently self-contained that it can be reverted […] without leaving any related changes behind”.
+* A commit should be, to quote shadowm, “sufficiently <strong>self-contained</strong> that it can be reverted […] without leaving any related changes behind”.
-** A commit to a long-running (or otherwise non-topic) branch should work on its own, without requiring subsequent commits.
+** A commit to a long-running (or otherwise non-topic) branch should <strong>work on its own</strong>, without requiring subsequent commits.
-*** It’s fine for a commit to not work (or only partially work) if it’s a commit to a temporary topic branch, which is to be merged into (not rebased onto) another branch when the commit series achieves full functionality.
+*** It’s fine for a commit to not work (or only partially work) if it’s a commit to a temporary topic branch, which is to be merged into (<em><strong>not</strong></em> rebased onto) another branch when the commit series achieves full functionality.
 == Commit messages ==
 * A commit message consists of a summary line and a message body, which must be separated with a blank line.
-* The message body should describe and explain the changes made in the commit as fully as possible.
+* The message body should <strong>describe and explain</strong> the changes made in the commit <strong>as fully as possible</strong>.
-** The message body should be hard-wrapped to 72 characters (or 72 columns; some characters can occupy multiple columns).
+** The message body should be hard-wrapped to <strong>72 characters</strong> (or 72 columns; some characters can occupy multiple columns).
-* The summary line should summarize the message body in such a way as to be as useful as possible for developers reviewing the commit history in the future.
+* The summary line should <strong>summarize</strong> the message body in such a way as to be as useful as possible for developers reviewing the commit history in the future.
 ** The summary line should be written in “imperative present tense”.
 ** The summary line should be a sentence, written without a full-stop character at the end.
@@ Line 15: / Line 15: @@
 == Pull requests ==
-* A pull request should always request the pull of a topic branch, never a long-running branch (like a ‘master’ branch).
+* A pull request should always request the pull of a <strong>topic branch, never a long-running branch</strong> (like a ‘master’ branch).
-* A pull request should be self-contained, like a commit should be.
+* A pull request should be <strong>self-contained</strong>, like a commit should be.

@@ Line 1: / Line 1: @@
 == Commits ==
-* A commit should be, to quote shadowm, “sufficiently self-contained that it can be reverted and reapplied as many times as you want without leaving any related changes behind”.
+* A commit should be, to quote shadowm, “sufficiently self-contained that it can be reverted […] without leaving any related changes behind”.
 ** A commit to a long-running (or otherwise non-topic) branch should work on its own, without requiring subsequent commits.
 *** It’s fine for a commit to not work (or only partially work) if it’s a commit to a temporary topic branch, which is to be merged into (not rebased onto) another branch when the commit series achieves full functionality.

@@ Line 2: / Line 2: @@
 * A commit should be, to quote shadowm, “sufficiently self-contained that it can be reverted and reapplied as many times as you want without leaving any related changes behind”.
 ** A commit to a long-running (or otherwise non-topic) branch should work on its own, without requiring subsequent commits.
-*** It’s fine for a commit to not work (or only partially work) if it’s a commit to a short-lived topic branch, which is to be merged into (not rebased onto) another branch when the commit series achieves full functionality.
+*** It’s fine for a commit to not work (or only partially work) if it’s a commit to a temporary topic branch, which is to be merged into (not rebased onto) another branch when the commit series achieves full functionality.
 == Commit messages ==