We are using git for development of PeerLibrary. You can learn its basics and general version control vocabulary.

PeerLibrary development model roughly follows this git branching model. Main difference is that we have releases, but at the same time we regularly update master branch with new smaller backwards-compatible features and push them to our users. We release new versions when there are backwards-incompatible changes which require more testing to determine that upgrade path works. Additionally, even for project members with push access to the repository, we are using GitHub pull requests to achieve code review for any code pushed to the repository.

Steps are as follows:

1. Envision your modular change you will be making. Do not try to make too many changes at the same time. Do not mix major style and refactoring changes with programming logic changes. If you have a proposal to refactor the code, make a pull request with only those changes so that it is easy to reason that old and new code behave the same.
2. Decide on which branch (master or development) you want to base your development from. The development branch is where active development happens. Development in master branch is done only for bugfixes and smaller features which do not change data and APIs (mostly user interface improvements). If you are unsure consult others, but you should probably start from development branch.
3. Create a new branch from the base branch you have chosen. All pull requests that encompass major units should contain the following components by the time they are merged: code, documentation (which may be just descriptive comments in code), schema migrations, and tests. We try to define and use internal (or even external) APIs as much as possible and always have in mind if you can abstract your code into API. Tests and documentation should be done accordingly.
4. Make the change(s) in that branch on your local machine.
5. Commit and push changes to the branch.
6. Create a pull request against your base branch for the proposed changes as soon as possible. This allows others to know about the changes you are working on.
7. When you are ready to have the changes reviewed (this can be multiple times during the pull request development), post a comment to let the community know that you would like someone to look over the code in your pull request and label a pull request with code review needed GitHub label. (NOTE: Comments on pull requests send e-mails to project members, while pushing commits do not. This is why a comment is important to alert others of your changes, and also to clarify that they are ready for review.)
8. At least one other project member should review your code, make comments and suggestions, which you should address, and let you know when they believes that the pull request is ready for merge. This is an iterative process.
9. After you are satisfied with the pull request as well, you should merge it yourself.