Return to README.GIT-RULES CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / php

php 5.4.29

    1: ====================
    2:   Git Commit Rules
    3: ====================
    4: 
    5: This is the first file you should be reading when contributing code via Git.
    6: We'll assume you're basically familiar with Git, but feel free to post
    7: your questions on the mailing list. Please have a look at
    8: http://git-scm.com/ for more detailed information on Git.
    9: 
   10: PHP is developed through the efforts of a large number of people.
   11: Collaboration is a Good Thing(tm), and Git lets us do this. Thus, following
   12: some basic rules with regards to Git usage will::
   13: 
   14:    a. Make everybody happier, especially those responsible for maintaining
   15:       Git itself.
   16: 
   17:    b. Keep the changes consistently well documented and easily trackable.
   18: 
   19:    c. Prevent some of those 'Oops' moments.
   20: 
   21:    d. Increase the general level of good will on planet Earth.
   22: 
   23: Having said that, here are the organizational rules::
   24: 
   25:    1. Respect other people working on the project.
   26: 
   27:    2. Discuss any significant changes on the list before committing and get
   28:       confirmation from the release manager for the given branch.
   29: 
   30:    3. Look at EXTENSIONS file to see who is the primary maintainer of
   31:       the code you want to contribute to.
   32: 
   33:    4. If you "strongly disagree" about something another person did, don't
   34:       start fighting publicly - take it up in private email.
   35: 
   36:    5. If you don't know how to do something, ask first!
   37: 
   38:    6. Test your changes before committing them. We mean it. Really.
   39:       To do so use "make test".
   40: 
   41:    7. For development use the --enable-maintainer-zts switch to ensure your
   42:       code handles TSRM correctly and doesn't break for those who need that.
   43: 
   44: Currently we have the following branches in use::
   45: 
   46:   master    The active development branch. 
   47: 
   48:   PHP-5.5   Is used to release the PHP 5.5.x series. This is a current
   49:             stable version and is open for bugfixes only.
   50: 
   51:   PHP-5.4   Is used to release the PHP 5.4.x series. This is a current
   52:             stable version and is open for bugfixes only.
   53: 
   54:   PHP-5.3   Is used to release the PHP 5.3.x series. This is currently 
   55:             in extended support and open forsecurity fixes only. Triaged
   56:             via security@php.net
   57: 
   58:   PHP-5.2   This branch is closed.
   59: 
   60:   PHP-5.1   This branch is closed.
   61: 
   62:   PHP-4.4   This branch is closed.
   63: 
   64: The next few rules are more of a technical nature::
   65: 
   66:    1. All changes should first go to the lowest branch (i.e. 5.3) and then 
   67:       get merged up to all other branches. If a change is not needed for
   68:       later branches (i.e. fixes for features which where dropped from later
   69:       branches) an empty merge should be done.
   70: 
   71:    2. All news updates intended for public viewing, such as new features,
   72:       bug fixes, improvements, etc., should go into the NEWS file of *any
   73:       stable release* version with the given change. In other words,
   74:       news about a bug fix which went into PHP-5.4, PHP-5.5 and master
   75:       should be noted in both PHP-5.4/NEWS and PHP-5.5/NEWS but
   76:       not master, which is not a public released version yet.
   77: 
   78:    3. Do not commit multiple file and dump all messages in one commit. If you
   79:       modified several unrelated files, commit each group separately and
   80:       provide a nice commit message for each one. See example below.
   81: 
   82:    4. Do write your commit message in such a way that it makes sense even
   83:       without the corresponding diff. One should be able to look at it, and
   84:       immediately know what was modified. Definitely include the function name
   85:       in the message as shown below.
   86: 
   87:    5. In your commit messages, keep each line shorter than 80 characters. And
   88:       try to align your lines vertically, if they wrap. It looks bad otherwise.
   89: 
   90:    6. If you modified a function that is callable from PHP, prepend PHP to
   91:       the function name as shown below.
   92: 
   93: 
   94: The format of the commit messages is pretty simple.
   95: 
   96: <max 79 characters short description>\n
   97: \n
   98: <long description, 79 chars per line>
   99: \n
  100: 
  101: An Example from the git project (commit 2b34e486bc):
  102: 
  103: pack-objects: Fix compilation with NO_PTHREDS
  104:   
  105: It looks like commit 99fb6e04 (pack-objects: convert to use
  106: parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
  107: hasn't noticed that the 'arg' variable no longer is available.
  108: 
  109: If you fix some bugs, you should note the bug ID numbers in your
  110: commit message. Bug ID should be prefixed by "#" for easier access to
  111: bug report when developers are browsing CVS via LXR or Bonsai.
  112: 
  113: Example::
  114: 
  115:   Fixed bug #14016 (pgsql notice handler double free crash bug.)
  116: 
  117: When you change the NEWS file for a bug fix, then please keep the bugs
  118: sorted in decreasing order under the fixed version.
  119: 
  120: You can use OpenGrok (http://lxr.php.net/) and gitweb (http://git.php.net/)
  121: to look at PHP Git repository in various ways.
  122: 
  123: 
  124: For further information on the process and further details please refer to
  125: https://wiki.php.net/vcs/gitworkflow and https://wiki.php.net/vcs/gitfaq
  126: 
  127: Happy hacking,
  128: 
  129: PHP Team