

Quick-start
=============================

* Our git repository is at https://github.com/pyinstaller/pyinstaller::

    git clone https://github.com/pyinstaller/pyinstaller

  - Development is done on the `develop` branch. Pull-request shall be filed
    against this branch.

  - Releases will reside on the `master` branch.

* Install required testing tools::

    pip install -r tests/requirements-tools.txt
    
* Commit often and in logical chunks. Try to make small patches, consistent
  increments. :ref:`»» Detailed Commit Guideline <Guidelines for Commits>`

* Provide tests that cover your changes and try to run the tests locally
  first.

* Reformatting code without functional changes will generally not be accepted
  (for rational see :issue:`2727`).

* Write meaningful commit messages in in the present tense, document what
  you’re doing and why.
  :ref:`»» Detailed Commit Message Rules <commit messages>`

* Submit pull-requests against the ``develop`` branch.

* For new files mind adding the copyright header, see
  |PyInstaller/init.py|_
  (also mind updating to the current year).

.. |PyInstaller/init.py| replace:: :file`:PyInstaller/__init__.py`
.. _PyInstaller/init.py: https://github.com/pyinstaller/pyinstaller/blob/develop/PyInstaller/__init__.py


.. _Guidelines for Commits:

Guidelines for Commits
=============================

* **Commit often and in logical chunks.**
  A commit should be one (and just one) logical unit. It should be something
  that someone might want to patch or revert in its entirety, and never
  piecewise. If it could be useful in pieces, make separate commits.

* **Write meaningful commit messages.**
  Using atomic commits will result in short, clear, and concise commit messages.
  Non-atomic commits make for awful run-on commit messages.

* Try to make small patches (i.e. work in consistent increments).

* Separate changes that affect functionality from those that just affect code
  layout, indendation, whitespace, filenames etc. This means that when looking
  at patches later, we don't have to wade through loads of non-functional
  changes to get to the important parts of the patch.

* Especially don't mix different types of change, and put a standard prefix
  for each type of change to identify it in your commit message.

* Restrict all whitespace changes to a specific type and document as such.

* Restrict refactorings (that should not change functionality) to their own
  commit (and document).

* Restrict functionality changes (bug fix or new feature) to their own
  changelists (and document).

* If possible, commit often. This helps to avoid conflicts.

* Only push when your tree passes validation: see TestingPatches.

* Discuss anything you think might be controversial before pushing it.

.. include:: ../_common_definitions.txt

.. Emacs config:
 Local Variables:
 mode: rst
 ispell-local-dictionary: "american"
 End:
