This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata

Getting ready to contribute to NetBeans

Adhere to the ASF Code of Conduct

Please read the Apache Software Foundation Code of Conduct and adhere to it. Pull Requests that violate the ASF Code of Conduct will be rejected.

Your PR may take time to be reviewed by a committer, specially during release phases, so be patient.

Bootstrapping (needs to be done only once)

Since you don't have write permissions to the github apache mirror, you need to fork locally.
You need to clone the forked repository and setup your name and email in github. This will also help git to rebase in order to fulfill its task.

Assuming your fork is at you can clone the forked repository to a local folder using the following command

git clone

Use following commands to set your username and email

git config --global "John Doe"
git config --global ""

--global can be removed if you want to setup only the current repository.

Also add the Apache NetBeans incubator project as your upstream in order to submit PRs:

git remote add upstream

Use branches

You need to create a Pull Request for a fix or a new feature. Pull Requests are not fixed in time. If you change your history the PR will be impacted.

 A PR will be reviewed by committers and they may ask you additional work.To ease your work it's better to create a branch per feature that you want to submit as Pull Request.

Creating and pointing at a new branch from master requires 3 steps:

  1. git checkout master
  2. git branch mywork
  3. git checkout mywork

You may then implement your changes, commit and push to your forked repository. You can then use the github UI to create a Pull request from your branch.

The commit message related to JIRA issue must start with [NETBEANS-<issue number>]

Squashing commits on a Pull Request

Before submitting your Pull Request it should ideally consist of a single commit only. Consider you've done the following on your branch:

[NETBEANS-xxx] Improved YAML lexer
Improved ability for night vision and
the robustness on I/O errors.
Oops, forgot to include lic file
Javadoc update - corrected spelling

If the PR is merged into master as-is then all these commits will be in the master too, forever. Therefore, in this example, all three commits should be squashed into one so that only X is left.

After submission (and certainly after someone starts reviewing the PR) you shouldn't touch the PR's history.

Keeping your own fork in sync with Apache GitHub repo

<to be described :  possible link we can use:>

git fetch upstream
git checkout master
git merge upstream/master

Tip: Syncing your fork only updates your local copy of the repository. To update your fork on GitHub, you must push your changes

git push origin master

Updating a stale Pull Request

Over time your Pull Request is likely to go stale. A "stale" pull request is one that is no longer up to date with the main line of development, and it needs to be updated before it can be merged into the project. This typically happens because there 've meanwhile been changes in the main branch on the same files that are included in the PR, thus resulting in a merge conflict.

<to be described :  possible link we can use:>


Contribution Guidelines

  1. Before starting to code, it is a good practice to open an issue (PTR) first and discuss it in the developer mailing list (Mailing lists), giving the reason for submitting your pull request so that it is clear and more experienced members can suggest appropriate solutions/ideas.
  2. All commits must include the author's full name and email address. For important modifications you will need to submit an Individual Contributor License Agreement (ICLA) .
  3. All new files must include the Apache Software Foundation license header. See any NetBeans source code in case of doubt.
  4. All commits must contain a meaningful commit message.
    1. A meaningful commit message holds in the first line a summary of the commit and in the body (beginning on the third-line) an explanation of what was changed and why it was done.
    2. Remember that in the future this commit message is most probably the only source of information why a change was committed to the code base.
    3. If the commit fixes a reported issue, the summary line should hold the issue number and title "[NETBEANS-XXX] Maven pom.xml file corrupted after inserting dependecies" for example.
  5. A Pull Request can consist of multiple commits. These commits should group the changes into meaningful entities. Fixup commits should be squashed into the base commit they fix.
  6. For contributors: Be prepared to be asked questions about your PR.
    1. A reviewer might have questions and you should be able to answer why you did a fix in a certain way and why it is safe and appropriate.
    2. Remember that the review sometimes takes as long, as creating a patch in the first place.
    3. Good commit messages help as they anticipate questions.
  7. For reviewers: Keep in mind that the contributor wants to fix a problem and has put effort into it. So be polite and focused.
  8. Don't change code that is correct and works.
    1. Consider a simple loop. In many cases you can switch between for-loop, for-each-loop and stream construct. All are valid solutions, don't change the code if it is not broken.
    2. An improvement is a different case. For example a try-with-resource construct is in general more correct than the try-finally construct which many developers fail to implement correctly.
    3. Constructs leading to warnings from the javac are also good candidates for simple fixes.
  9. Run unit tests and, if you introduce new feature/fixes, add unit tests. So before you start your work, check that unit tests for the module you are working on run correctly and after you are done keep doing.
    1. If unit tests fail, fixing these would be a good addition to the code base (it would be good to use a separate commit for this)
  10. Keep your pull requests up-to-date. When the PR can't be merged directly (it can happen that changes are introduced into the code base, that conflict with your PR) you should then update it accordingly.
  11. Follow the coding conventions of the file. Your code should match that style and not stand out. For new files, please follow the code conventions for the NetBeans code base:
  12. Try to keep the code readable, maintainable, easy to debug and performant.

And remember: These are guidelines, not laws.


If the source code might be translated to other languages then please add the comment `// NOI18N` to the string literals that must not be translated. Strings to be translated should be properly added to resource bundles.

If the source code is not to be translated then avoid adding `// NOI18N` comments to the string literals; this just adds clutter and makes the code less readable.



  • No labels