Difference between revisions of "User:8680/GitGoodPractice"

From The Battle for Wesnoth Wiki
(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...")
 
(Commits)
Line 1: Line 1:
 
== Commits ==
 
== 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 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.
+
** 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.
  
 
== Commit messages ==
 
== Commit messages ==

Revision as of 01:26, 14 March 2014

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 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.

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.