Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Virgo/Development
Contents
Coding style
Coding guide lines are documented here.
Null analysis
JDT Null Analysis capabilities are used and classes have to be annotated with annotations @Nullable, @NonNull, @NonNullByDefault as appropriate.
Branching model
The Virgo Team uses a simplified git-flow branching model where the main branch is master and every non-trivial code change must take place in a temporary branch (feature branch) that will be merged into master when development is completed and tested.
Every new development is tracked by a corresponding bugzilla entry and feature branches follow the naming convention feature/<id> where <id> corresponds to the numeric identifier of the bugzilla entry.
Committers may decide to create the feature branches manually or to use the git-flow addon for the git command-line client or the EGit git-flow addon. If using git-flow addons, make sure to initialize git-flow specifying that the development branch is named master and that the production branch is named production as in the sample command-line transcript below. In this way when a git-flow feature is completed it is automatically merged into master.
> git flow init Branch name for production releases: [master] production Branch name for "next release" development: [develop] master How to name your supporting branch prefixes? Feature branches? [feature/] Release branches? [release/] Hotfix branches? [hotfix/] Support branches? [support/] Version tag prefix? []
Commit messages
Commit messages follow the git recommended guide lines summarized below.
- First line is the summary line
- Then a blank line
- Remaining text is the detailed description
For example:
#12345 NullPointerException in MyClass Fix NPE due to missing check for null value. Originally the code was not checking for null. Now a proper check is done and the previously unhandled case is now gracefully reported.
Write commit detailed description in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug". This convention matches up with commit messages generated by commands like git merge and git revert.
Further paragraphs come after blank lines.
Bullet points are okay, typically a hyphen or asterisk is used for the bullet, preceded by a single space.
All lines should not exceed 72 characters to improve commit message readability from the command line.
Commit message template
It is recommend to take advantage of the Mylyn Bugzilla Connector and EGit Mylyn integration. After installing Mylyn, go to Preferenes -> Mylyn -> Team and enter the following template:
#${task.key}: ${task.description}
<detailed description here>
EGit will now prefill the commit message for you, using the details of the active task in the Mylyn Task List.
Committers not using Mylyn and Egit can create a file with the content below eg. ~/.gitmessage.txt and run the command git config --global commit.template ~/.gitmessage.txt
#task.key: <task.description> <detailed description here>