Skip to content

Issues and commits

bekaus edited this page Oct 20, 2011 · 2 revisions

Creating issues

  • Do not create issues in the public repository that may prematurely disclose our groups' new scientific ideas. We will provide a private repository for that.

Working on an issue

  • Assign yourself to the issue
  • Set the tag "next seven days"

Splitting large issues

If an issue takes more than 2 days of estimated ideal time, or if several developers should work together on it, create sub-issues as appropriate. Always cross-reference the original issue. (Cross-references to other issues are created by simply writing #xxx or gh-xxx, where xxx is the issue number).

Referencing issues in commits

If you commit changes (in git) that implement part of an issue's solution, always cross-reference the issue in the commit message using the above #xxx or gh-xxx syntax (the second form may be preferable when one wants to read messages outside of GitHub). A commit message may cross-reference several issues simultaneously.

This will automatically add the commit message as a new comment to the issue. Writing really informative commit messages is thus advisable. Git will automatically use the first line of the commit message as a short summary (to be displayed in the commit listing), so make sure to write good first lines.

Resolving issues

If a git commit finally resolves an issue, cross-reference the issue in the commit message by one of the following: fixes #xxx fixed #xxx fix #xxx closes #xxx close #xxx closed #xxx (where #xxx can - or should? - also be gh-xxx). This automatically adds the commit message as a new issue comment and closes the issue on GitHub, so write good commit messages. Make sure that you don't use one of these forms unintentionally when the issue shoudn't be closed.