First of all, thank you for wanting to contribute! We really appreciate all the awesome support we get from our community. We want to keep it as easy as possible to contribute changes that get things working in your environment. There are a few guidelines we need contributors to follow to keep the project flowing smoothly.
These guidelines are for code changes but we are always very grateful to receive other forms of contribution.
Before starting work on a functional change, i.e. a new feature, a change to an existing feature or a fixing a bug, please ensure an issue has been raised. Indicate your intention to do the work by writing a comment on the issue. This will prevent duplication of effort. If the change is non-trivial, it's usually best to propose a design in the issue comments before making a significant effort on the implementation.
It is not necessary to raise an issue for non-functional changes, e.g. refactoring, adding tests, reformatting code, documentation, updating packages, etc.
All new features must be covered by feature tests.
There is a single mainline branches master
which is used for trunk-based development work. All new features, changes, etc. must be applied to master
.
- Fork on GitHub
- Clone your fork locally
- Configure the
upstream
repo (git remote add upstream git://github.com/OpenMAVN/MAVN.Service.Dictionaries.git
) - Checkout
master
(git checkout master
) - Create a local branch (
git checkout -b my-branch
). The branch name should be descriptive, or it can just be the GitHub issue number which the work relates to, e.g.123
. - Work on your change
- Rebase if required (see 'Handling updates from
upstream
' below) - Test the build locally
- Push the branch up to GitHub (
git push origin my-branch
) - Send a pull request on GitHub (see 'Sending a Pull Request' below)
You should never work on a clone of master
, and you should never send a pull request from master
. Always use a feature/patch branch. The reasons for this are detailed below.
While you're working away in your branch it's quite possible that your upstream
master
may be updated. If this happens you should:
- Stash any un-committed changes you need to
git checkout master
git pull upstream master --ff-only
git checkout my-branch
git rebase master my-branch
git push origin master
(optional) this keepsmaster
in your fork up to date
These steps ensure your history is "clean" i.e. you have one branch from master
followed by your changes in a straight line. Failing to do this ends up with several "messy" merges in your history, which we don't want. This is the reason why you should always work in a branch and you should never be working in or sending pull requests from master
.
If you're working on a long running feature you may want to do this quite often to reduce the risk of tricky merges later on.
While working on your feature you may well create several branches, which is fine, but before you send a pull request you should ensure that you have rebased back to a single "feature/patch branch". We care about your commits, and we care about your feature/patch branch, but we don't care about how many or which branches you created while you were working on it. 😄
When you're ready to go you should confirm that you are up to date and rebased with upstream
master
(see "Handling updates from upstream
" above) and then:
git push origin my-branch
- Send a descriptive pull request on GitHub.
- Make sure the pull request is from the branch on your fork to the
OpenMAVN/MAVN.Service.Dictionaries
master
. - If your changes relate to a GitHub issue, add the issue number to the pull request description in the format
#123
.
- Make sure the pull request is from the branch on your fork to the
- If GitHub determines that the pull request can be merged automatically, a test build will commence shortly after you raise the pull request. The build status will be reported on the pull request.
- If the build fails, there may be a problem with your changes which you will have to fix before the pull request can be merged. Follow the link to the build server and inspect the build logs to see what caused the failure.
- Occasionally, build failures may be due to problems on the build server rather than problems in your changes. If you determine this to be the case, please add a comment on the pull request and one of the maintainers will address the problem.
The maintainers will review your pull request and provide any feedback required.