Changes between Version 68 and Version 69 of WorkingWithGit


Ignore:
Timestamp:
Nov 6, 2016, 3:31:18 AM (7 years ago)
Author:
larryv (Lawrence Velázquez)
Comment:

remove "Commit messages" section, which was incorporated into the CommitMessages rewrite

Legend:

Unmodified
Added
Removed
Modified

  • WorkingWithGit

    v68 v69  
    5858git commit
    5959}}}
    60 which prompts you for the commit message. See the [#commitmessages section on commit messages in git] for more information on git conventions and expectations in commit messages.
     60which prompts you for the commit message. See CommitMessages for more information on git conventions and expectations in commit messages.
    6161
    6262Because of Git's distributed nature, a commit on your local machine is not immediately available on the central server, like it was with Subversion. This means that you can continue to prepare further changes in additional commits before you publish your changes as a set. In fact, it is a very common practice in Git to do many small changes that are logically consistent in themselves and then publish them in one step.
    … …  
    6868
    6969Note that the push will fail if the remote repository has new changes. Contrary to Subversion, it does not matter whether your changes conflict with the remote ones. If this happens, you must update your local working copy as described in the [#updating section on fetch the latest changes] and re-try the push.
    70 
    71 
    72 === Commit messages === #commitmessages
    73 
    74 {{{
    75 #!div style="background-color: lightyellow; padding: 0.25em;"
    76 TODO: This section needs to be merged with CommitRules
    77 }}}
    78 
    79 To set which text editor is used by git for writing commit messages, you can do either of:
    80  * Set {{{core.editor}}} in your Git config: {{{git config --global core.editor "emacs"}}}
    81  * Set the {{{GIT_EDITOR}}} environment variable: {{{export GIT_EDITOR=emacs}}}
    82 
    83 There are a number of conventions to writing Git commit messages. For a detailed explanation, see http://chris.beams.io/posts/git-commit/. As a tl;dr, here are seven short rules:
    84 
    85  1. Separate subject from body with a blank line
    86  1. Limit the subject line to 50 characters
    87  1. Capitalize the subject line
    88  1. Do not end the subject line with a period
    89  1. Use the imperative mood in the subject line
    90  1. Wrap the body at 72 characters
    91  1. Use the body to explain what and why vs. how
    92 
    93 Additionally, MacPorts has the following rules for references to tickets, pull requests and commits:
    94 
    95  * When referencing a ticket, use the full URL to  Trac: !https://trac.macports.org/ticket/<number>
    96  * When referencing a pull request, use !#12345
    97  * When referencing a commit, use a git commit hash: !bfc6af313273c79515df9bde4f3eaa2dd0f15276, which may be abbreviated to up to 7 characters: !bfc6af3
    98 
    99 If you don't want to remember these rules, you can configure your git client to load a template whenever it prompts you for a commit message by setting the `commit.template` [https://git-scm.com/docs/git-config git-config(1)] option. The KDE developers [https://quickgit.kde.org/?p=macports-kde.git&a=blob&h=14f952f776b9f54263671cc2aba5886c6ebee75b&f=contrib%2Fgit-setup%2F.git-commit-template&o=plain have a nice example].
    100 
    10170
    10271=== Fetching the latest changes === #updating