|
| 1 | +########################### |
| 2 | +Contributing to CodeIgniter |
| 3 | +########################### |
| 4 | + |
| 5 | +CodeIgniter is a community driven project and accepts contributions of code |
| 6 | +and documentation from the community. These contributions are made in the form |
| 7 | +of Issues or `Pull Requests <http://help.github.com/send-pull-requests/>`_ on |
| 8 | +the `EllisLab CodeIgniter repository |
| 9 | +<https://github.com/EllisLab/CodeIgniter>`_ on GitHub. |
| 10 | + |
| 11 | +Issues are a quick way to point out a bug. If you find a bug or documentation |
| 12 | +error in CodeIgniter then please check a few things first: |
| 13 | + |
| 14 | +- There is not already an open Issue |
| 15 | +- The issue has already been fixed (check the develop branch, or look for |
| 16 | + closed Issues) |
| 17 | +- Is it something really obvious that you fix it yourself? |
| 18 | + |
| 19 | +Reporting issues is helpful but an even better approach is to send a Pull |
| 20 | +Request, which is done by "Forking" the main repository and committing to your |
| 21 | +own copy. This will require you to use the version control system called Git. |
| 22 | + |
| 23 | +********** |
| 24 | +Guidelines |
| 25 | +********** |
| 26 | + |
| 27 | +Before we look into how, here are the guidelines. If your Pull Requests fail |
| 28 | +to pass these guidelines it will be declined and you will need to re-submit |
| 29 | +when you’ve made the changes. This might sound a bit tough, but it is required |
| 30 | +for us to maintain quality of the code-base. |
| 31 | + |
| 32 | +PHP Style |
| 33 | +========= |
| 34 | + |
| 35 | +All code must meet the `Style Guide |
| 36 | +<http://codeigniter.com/user_guide/general/styleguide.html>`_, which is |
| 37 | +essentially the `Allman indent style |
| 38 | +<http://en.wikipedia.org/wiki/Indent_style#Allman_style>`_, underscores and |
| 39 | +readable operators. This makes certain that all code is the same format as the |
| 40 | +existing code and means it will be as readable as possible. |
| 41 | + |
| 42 | +Documentation |
| 43 | +============= |
| 44 | + |
| 45 | +If you change anything that requires a change to documentation then you will |
| 46 | +need to add it. New classes, methods, parameters, changing default values, etc |
| 47 | +are all things that will require a change to documentation. The change-log |
| 48 | +must also be updated for every change. Also PHPDoc blocks must be maintained. |
| 49 | + |
| 50 | +Compatibility |
| 51 | +============= |
| 52 | + |
| 53 | +CodeIgniter is compatible with PHP 5.2.4 so all code supplied must stick to |
| 54 | +this requirement. If PHP 5.3 or 5.4 functions or features are used then there |
| 55 | +must be a fallback for PHP 5.2.4. |
| 56 | + |
| 57 | +Branching |
| 58 | +========= |
| 59 | + |
| 60 | +CodeIgniter uses the `Git-Flow |
| 61 | +<http://nvie.com/posts/a-successful-git-branching-model/>`_ branching model |
| 62 | +which requires all pull requests to be sent to the "develop" branch. This is |
| 63 | +where the next planned version will be developed. The "master" branch will |
| 64 | +always contain the latest stable version and is kept clean so a "hotfix" (e.g: |
| 65 | +an emergency security patch) can be applied to master to create a new version, |
| 66 | +without worrying about other features holding it up. For this reason all |
| 67 | +commits need to be made to "develop" and any sent to "master" will be closed |
| 68 | +automatically. If you have multiple changes to submit, please place all |
| 69 | +changes into their own branch on your fork. |
| 70 | + |
| 71 | +One thing at a time: A pull request should only contain one change. That does |
| 72 | +not mean only one commit, but one change - however many commits it took. The |
| 73 | +reason for this is that if you change X and Y but send a pull request for both |
| 74 | +at the same time, we might really want X but disagree with Y, meaning we |
| 75 | +cannot merge the request. Using the Git-Flow branching model you can create |
| 76 | +new branches for both of these features and send two requests. |
| 77 | + |
| 78 | +Signing |
| 79 | +======= |
| 80 | +You must sign your work, certifying that you either wrote the work or |
| 81 | +otherwise have the right to pass it on to an open source project. git makes |
| 82 | +this trivial as you merely have to use `--signoff` on your commits to your |
| 83 | +CodeIgniter fork. |
| 84 | + |
| 85 | +.. code-block:: bash |
| 86 | +
|
| 87 | + git commit --signoff |
| 88 | +
|
| 89 | +or simply |
| 90 | + |
| 91 | +.. code-block:: bash |
| 92 | +
|
| 93 | + git commit -s |
| 94 | +
|
| 95 | +This will sign your commits with the information setup in your git config, e.g. |
| 96 | + |
| 97 | + Signed-off-by: John Q Public <john.public@example.com> |
| 98 | + |
| 99 | +If you are using Tower there is a "Sign-Off" checkbox in the commit window. You |
| 100 | +could even alias git commit to use the -s flag so you don’t have to think about |
| 101 | +it. |
| 102 | + |
| 103 | +By signing your work in this manner, you certify to a "Developer's Certificate |
| 104 | +or Origin". The current version of this certificate is in the :doc:`/DCO` file |
| 105 | +in the root of this documentation. |
0 commit comments