-
Notifications
You must be signed in to change notification settings - Fork 18
General Overview
- Introduction
- Organization
- Implementation
- Advanced Topics
Thank you for your interest in contributing to the LIO project!
Before you start, please read this few pages and follow the guidelines we have established. Our work scheme is based mostly on the branching model proposed by Vincent Driessen in his page: http://nvie.com/posts/a-successful-git-branching-model/.
Basically, there are two main branches called master (which has the latest release version of the code) and develop (which has the last working incorporations, not yet polished and released). Each contributor should branch from and into develop when adding new features; when all desired features have been successfully implemented into develop, a “new release” branch is started and dedicated to catch any remaining bugs and polishing the code to incorporate it to master in a production-ready state.
If it is necessary to make a modification to the production code in master and it cannot wait for the next version, it can be done via hotfixes. A new branch is created from master, and once the problem is fixed, it is then merged into master and into develop (or into the current release branch instead of develop, if such branch exists).
Description still pending.
Article: https://guides.github.com/features/issues/
The most common way in which to contribute to the LIO project is either by adding a new feature or improving the way a feature is implemented. For any of these, the first step is to create a new branch from develop, where you will work in your contribution (1). Then, after you are done and have tested that the code works, you need to incorporate it back into the develop branch (2). Then you are done; your contribution will eventually be incorporated into the next release of LIO; you can delete your branch if you want, but please remain in touch in case any problem is detected with the code you modified.
Once all the required features have been successfully incorporated into develop, it is time to polish the final details and publish a new version of the production code. The version number must be determined and a new branch must be created from develop in order to work on all necessary modifications and test every possible aspect in the lookout for hidden bugs. Once the code is in a state ready for production it must be merged into master, and then back into develop. The new version of the code is now finished.
git checkout -b release-v2.1 develop
git checkout master
git merge --no-ff release-v2.1
git checkout develop
git merge --no-ff release-v2.1
If there is some urgent change that needs to be done to master, a new branch must be created from it.