Fluid Infusion uses a git repository hosted on github for source code management. All of the code that is included in an Infusion release lives in the master branch. The project repository should always be in a working state. Daily builds are generated and releases are all cut from the master branch of the project repository.
If you have a github account and a fork of the Fluid Infusion repository, you can submit Pull requests directly through github. When sending a Pull Request, please send the request from a branch named after the jira issue it addresses (e.g. FLUID-xxxx). Also include all relevant information in the comments. If you know who you want to look at your Pull Request you can mention them using the @githubID syntax. Please also post a link and description of your Pull Request on the jira issue and as a message to the fluid-work mailing list.
(see: Sending Pull Requests)
Patches are a useful means of sharing code changes without having to commit into the repository. Since patches are just plain text files, they can attached to JIRA issues, included as an attachment to e-mails, etc.
When creating a patch you should try to make the name descriptive, so that others will be easily able to know what it does. By convention Fluid community members tend to name the files with the JIRA number with a .patch suffix (i.e.
Navigate to the branch that you would like to create the patch from and run the following command.
git format-patch master --stdout > FLUID-xxxx.patch
Once you have created a patch you'll want to share it back to the community. The easiest way to keep track of patches is to attach them straight to the JIRA that they are for. If you can't use JIRA for any reason, you can email your patch directly to the fluid-work mailing list.
Once you've posted your patch, sending a note to the fluid-work list and/or pinging someone in the #fluid-work irc channel is a great way to get the community looking at your patch.
The first step to becoming a committer is by making yourself familiar to the community (see: Collaborate).
When you are ready to contribute code:
Code should, where possible, be accompanied by unit tests and regular code review should be expected and solicited. For more information, see the Coding and Commit Standards page.