Development Guide


  • Our git repository is at

    git clone
    • 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. »» Detailed Commit Guideline

  • 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 #2727).

  • Write meaningful commit messages in in the present tense, document what you’re doing and why. »» Detailed Commit Message Rules

  • Submit pull-requests against the develop branch.

  • For new files mind adding the copyright header, see :file`:PyInstaller/` (also mind updating to the current year).

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.