Simple contribution guidelines to make open-source happy and organized
It's difficult for us developers to stay organized and adequately track changes in our code. This difficulty is amplified on teams of more than one. It's further amplified by distributed teams and time zones. It's even more amplified in open-source. With the guide below, open-source can be organized. It can be a happy place. Resist being a lazy developer, we can get through this together.
master
branch is always stable and release-readydevelop
branch is not guaranteed to be stable, it is for development and merged intomaster
when stable- feature branches should be created for adding new features and merged into
develop
when finished
- Find a feature or bug to work on
- Fork the repo if you haven't already
- Create a new branch with a sweet name:
git checkout -b bug_<nameOfBug>
orgit checkout -b feature_<nameOfFeature>
- Do some programming
- Write unit tests, if possible
- Keep your code nice and clean by adhering to coding standards & guidelines
- Don't break anything, like unit tests
- Update the documentation/comments, if needed
- Merge the latest from the
develop
branch and resolve any conflicts (before submitting a pull request!) - Submit a pull request to the
develop
branch from your bug/feature branch