The Neo4j community is a free software and open source community centered around software and components for the Neo4j Graph Database. It is sponsored by Neo Technology, which provides infrastructure (different kinds of hosting, documentation, etc) as well as people to manage it. The Neo4j community is an open community, in so far as it welcomes any member that accepts the basic criterias of contribution and adheres to the community’s Code of Conduct.

Contribution can be in many forms (documentation, discussions, bug reports). This document outlines the rules of governance for a contributor of code.

In a nutshell, you need to be aware of the following fundamentals if you wish to contribute code:

Every individual that contributes code does so in the context of a role (a single individual can have multiple roles). The role defines their responsibilities and privileges:

Code contributions to Neo4j are normally done via Github Pull Requests, following the workflow shown below. Please check the pull request checklist before sending off a pull request as well.

You have a much higher chance of getting your changes accepted if you supply us with small, readable unit tests covering the code you’ve written. Also, make sure your code doesn’t break any existing tests. Note that there may be downstream components that need to be tested as well, depending on what you change.

To run tests, use Maven rather than your IDE to ensure others can replicate your test run. The command for running Neo4j tests in any given component is mvn clean validate.

The Neo4j Code style is maintained on GitHub in styles for the different IDEs.

Please take some care in providing good commit messages. Use your common sense. In particular:

One crucial aspect of contributing is the Contributor License Agreement. In short: make sure to sign the CLA, or the Neo4j project won’t be able to accept your contribution.

Because we would like each contribution to be contained in a single commit, merge commits are not allowed inside a pull request. Merges are messy, and should only be done when necessary, eg. when merging a branch into master to remember where the code came from.

If you want to update your development branch to incorporate the latest changes from master, use git rebase. For details on how to use rebase, see Git manual on rebase: the Git Manual.

If you have multiple commits, you should squash them into a single one for the pull request, unless there is some extraordinary reason not to. Keeping your changes in a single commit makes the commit history easier to read, it also makes it easy to revert and move features around.

One way to do this is to, while standing on your local branch with your changes, create a new branch and then interactively rebase your commits into a single one.

Interactive rebasing with Git. 

# On branch mychanges
git checkout -b mychanges-clean

# Assuming you have 4 commits, rebase the last four commits interactively:
git rebase -i HEAD~4

# In the dialog git gives you, keep your first commit, and squash all others into it.
# Then reword the commit description to accurately depict what your commit does.
# If applicable, include any issue numbers like so: #760

For more details, see the git manual: http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages

If you are asked to modify parts of your code, work in your original branch (the one with multiple commits), and follow the above process to create a fixed single commit.