If your code makes sense and clearly will be used in future, follows the style and Of lines affected by your change approaches 1000, it is a good reason to split pull requestĭon't hesitate to publish work which is not yet completed from user/product/feature perspective. Touching up to 200 lines are okay, up to 500 lines are acceptable. The smaller is your pull request, the easier and faster is the review. Better code is more readable, is less error-prone Your code must be reviewed before it is merged into the main code base. The chosen base branch from bardsoftware/ganttproject repo. When you committed and pushed the changes, If your new code is not purely UI, it normally should come with tests. There is a module ganttproject-tester withĪ few dozens of JUnit tests and useful test harness. Unfortunately by far not the wholeĬode base is covered. We write unit tests whenever it makes sense. The following snippet follows our code style: Use prefix my in the names of local variables and function arguments. The purpose of prefix my is to be able to distinguish member and local variables Static objects which are mutable per se shouldīe prefixed with our. member variables in classes should be prefixed with prefix my.Block indent is 2 spaces, line wrapping is 4 spaces.Add copyright header and license notice in the new files (see below).Please follow Java code style when hacking. The most important rule: publish early and keep changes small. Tab and get shell completions after typing git checkout). Where is the number of the issue and is aįew words describing the purpose of the branch (handy when you run git branch or hit Then your branch should be named like tkt. (it is a good idea to create one before you start hacking) Which is perfectly described at the link. TL DR: Create branch per feature, follow the style, write tests, publish small pull requests early rather than later Fork the repository ¶įirst-time contributors will have to fork GanttProject repository into their own GitHub account. Text below gives more details on these steps. Hack, test, commit, push, create a pull request and passĬode review. In short, you need to make your own fork of our repository on GitHub,Ĭreate a branch forked from master (unless there is a good reason to choose some other branch), In order to make a change and integrate it into GanttProject build you need to follow New features normally shall be targeted to master branch. Bugfixes should be merged to the version branch first and to master afterwards. Longer answer depends on theīugfixes to some particular minor version shall be targeted to version branches. Short answer: send pull requests against master. How to check out, compile and run GanttProject Master using command line tools and IDEs.How to check out, compile and run GanttProject 2.8 using command line tools and IDEs.Build process is slightly different for stable GanttProject Pilsen and work-in-progress GanttProject Master.
0 Comments
Leave a Reply. |