Child pages
  • Version Control System Philosophy of TSPHP

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Commits should be as small as possible. Preferably one change per commit. That does not mean that a commit for every changed character is necessary, but for each resolved issue and if it is a big issue for each sub-problem of the issue. It is perfectly fine to have several commits within one push tough.

  2. Follow the following commit message guidelines (adopted from
    Each commit comprises a title and a body where the title is the issue number following by its title and the body (separated by a blank line from the tile) mentions what has been done. The title should ideally be not longer than 50 characters and 100 at max. Try to be more concise (and rewrite the title in JIRA as well) if the title is longer than 100 characters long. An example

    Code Block
    TSPHP-77 grammar for simple calculator
    added + - * /, still missing are ^ ( )

    If you have solved more than one sub-problem within one commit, then preferably list the sub-problems as follows:

    Code Block
    TSPHP-77 grammar for simple calculator
    - added + - * /, still missing are ^ ( )
    - grouped operators in one rule

    In the case where you have solved more than one issue within one commit (try to avoid this whenever possible, commit regularly as mentioned in point 1 above), then use the most important issue as title. Further issues follow the same principle as above and are separated with blank line from the comment of the previous issue. Following an example:

    Code Block
    TSPHP-820 Falseable types
    - introduced new modifier for falseable types
    - removed nullable scalar types -> information is stored in ICanBeNullable
    TSPHP-759 casts not over multiple levels
    - removed the corresponding behaviour
    - adopted the tests accordingly
  3. Make a branch per independent issue, this way you can create several pull request at the same time.
  4. Make sure to run the ant target dist on your local machine before creating a pull request. Check that all tests pass and that the code quality is allright (consult QA.html in the /build/ folder)
  5. Make sure that you have included tests for new functionalities or that tests cover your changes before you create a pull request.
  6. Do not commit products (code/artefacts etc.) which are a result of a build or a result of another generation utility.
  7. It is recommended to commit and create pull requests regularly and to fetch regularly from the upstream repository (from GitHub) to avoid conflicts