2012-04-13 08:12:47 +08:00
|
|
|
====================
|
|
|
|
Git Commit Rules
|
|
|
|
====================
|
|
|
|
|
|
|
|
This is the first file you should be reading when contributing code via Git.
|
|
|
|
We'll assume you're basically familiar with Git, but feel free to post
|
|
|
|
your questions on the mailing list. Please have a look at
|
|
|
|
http://git-scm.com/ for more detailed information on Git.
|
|
|
|
|
|
|
|
PHP is developed through the efforts of a large number of people.
|
|
|
|
Collaboration is a Good Thing(tm), and Git lets us do this. Thus, following
|
|
|
|
some basic rules with regards to Git usage will::
|
|
|
|
|
|
|
|
a. Make everybody happier, especially those responsible for maintaining
|
|
|
|
Git itself.
|
|
|
|
|
|
|
|
b. Keep the changes consistently well documented and easily trackable.
|
|
|
|
|
|
|
|
c. Prevent some of those 'Oops' moments.
|
|
|
|
|
|
|
|
d. Increase the general level of good will on planet Earth.
|
|
|
|
|
|
|
|
Having said that, here are the organizational rules::
|
|
|
|
|
|
|
|
1. Respect other people working on the project.
|
|
|
|
|
|
|
|
2. Discuss any significant changes on the list before committing and get
|
|
|
|
confirmation from the release manager for the given branch.
|
|
|
|
|
|
|
|
3. Look at EXTENSIONS file to see who is the primary maintainer of
|
|
|
|
the code you want to contribute to.
|
|
|
|
|
|
|
|
4. If you "strongly disagree" about something another person did, don't
|
|
|
|
start fighting publicly - take it up in private email.
|
|
|
|
|
|
|
|
5. If you don't know how to do something, ask first!
|
|
|
|
|
|
|
|
6. Test your changes before committing them. We mean it. Really.
|
|
|
|
To do so use "make test".
|
|
|
|
|
|
|
|
7. For development use the --enable-maintainer-zts switch to ensure your
|
|
|
|
code handles TSRM correctly and doesn't break for those who need that.
|
|
|
|
|
|
|
|
Currently we have the following branches in use::
|
|
|
|
|
|
|
|
master The active development branch.
|
|
|
|
|
2013-06-20 17:51:21 +08:00
|
|
|
PHP-5.5 Is used to release the PHP 5.5.x series. This is a current
|
|
|
|
stable version and is open for bugfixes only.
|
2012-04-13 08:12:47 +08:00
|
|
|
|
2013-06-20 17:51:21 +08:00
|
|
|
PHP-5.4 Is used to release the PHP 5.4.x series. This is a current
|
2012-04-13 08:12:47 +08:00
|
|
|
stable version and is open for bugfixes only.
|
|
|
|
|
2013-06-20 17:51:21 +08:00
|
|
|
PHP-5.3 Is used to release the PHP 5.3.x series. This is currently
|
|
|
|
in extended support and open forsecurity fixes only. Triaged
|
|
|
|
via security@php.net
|
|
|
|
|
|
|
|
PHP-5.2 This branch is closed.
|
2012-04-13 08:12:47 +08:00
|
|
|
|
|
|
|
PHP-5.1 This branch is closed.
|
|
|
|
|
|
|
|
PHP-4.4 This branch is closed.
|
|
|
|
|
|
|
|
The next few rules are more of a technical nature::
|
|
|
|
|
|
|
|
1. All changes should first go to the lowest branch (i.e. 5.3) and then
|
|
|
|
get merged up to all other branches. If a change is not needed for
|
|
|
|
later branches (i.e. fixes for features which where dropped from later
|
|
|
|
branches) an empty merge should be done.
|
|
|
|
|
|
|
|
2. All news updates intended for public viewing, such as new features,
|
|
|
|
bug fixes, improvements, etc., should go into the NEWS file of the
|
|
|
|
*first* to be released version with the given change. In other words
|
|
|
|
any NEWS file change only needs to done in one branch.
|
|
|
|
|
|
|
|
3. Do not commit multiple file and dump all messages in one commit. If you
|
|
|
|
modified several unrelated files, commit each group separately and
|
|
|
|
provide a nice commit message for each one. See example below.
|
|
|
|
|
|
|
|
4. Do write your commit message in such a way that it makes sense even
|
|
|
|
without the corresponding diff. One should be able to look at it, and
|
|
|
|
immediately know what was modified. Definitely include the function name
|
|
|
|
in the message as shown below.
|
|
|
|
|
|
|
|
5. In your commit messages, keep each line shorter than 80 characters. And
|
|
|
|
try to align your lines vertically, if they wrap. It looks bad otherwise.
|
|
|
|
|
|
|
|
6. If you modified a function that is callable from PHP, prepend PHP to
|
|
|
|
the function name as shown below.
|
|
|
|
|
|
|
|
|
|
|
|
The format of the commit messages is pretty simple.
|
|
|
|
|
|
|
|
<max 79 characters short description>\n
|
|
|
|
\n
|
|
|
|
<long description, 79 chars per line>
|
|
|
|
\n
|
|
|
|
|
|
|
|
An Example from the git project (commit 2b34e486bc):
|
|
|
|
|
|
|
|
pack-objects: Fix compilation with NO_PTHREDS
|
|
|
|
|
|
|
|
It looks like commit 99fb6e04 (pack-objects: convert to use
|
|
|
|
parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
|
|
|
|
hasn't noticed that the 'arg' variable no longer is available.
|
|
|
|
|
|
|
|
If you fix some bugs, you should note the bug ID numbers in your
|
|
|
|
commit message. Bug ID should be prefixed by "#" for easier access to
|
|
|
|
bug report when developers are browsing CVS via LXR or Bonsai.
|
|
|
|
|
|
|
|
Example::
|
|
|
|
|
|
|
|
Fixed bug #14016 (pgsql notice handler double free crash bug.)
|
|
|
|
|
|
|
|
When you change the NEWS file for a bug fix, then please keep the bugs
|
|
|
|
sorted in decreasing order under the fixed version.
|
|
|
|
|
|
|
|
You can use OpenGrok (http://lxr.php.net/) and gitweb (http://git.php.net/)
|
|
|
|
to look at PHP Git repository in various ways.
|
|
|
|
|
|
|
|
|
|
|
|
For further information on the process and further details please refer to
|
|
|
|
https://wiki.php.net/vcs/gitworkflow and https://wiki.php.net/vcs/gitfaq
|
|
|
|
|
|
|
|
Happy hacking,
|
|
|
|
|
|
|
|
PHP Team
|