Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Cytoscape Core Branch Management
The following is a good overview for this branching model:
How to Commit Your Changes
Commit your changes to develop branch. Creating feature branches is encouraged. Make sure you call:
git pull --rebase
before pushing your changed to upstream. This keeps commit tree clean.
Once we are ready for release, release branch will be created. The naming convention is release/VERSION_NUMBER. In this phase, there is only one important rule:
COMMIT ALL YOUR FIXES TO RELEASE BRANCH
Once you fix a bug, commit your changes to are review and issues are found, it is the developer's responsibility to revert the change or commit another fix.
- Make your commit small. Best practice is one commit per bug. Use fixes #BUGID tag to associate your commit with issue tracker (redmine)
- Reverting fix is always OK
DO NOT USE CHERRY PICK. DO NOT MIX BUG FIXES AND NEW FEATURES IN SINGLE COMMIT
In general, if you need to use cherry-pick, something is wrong. In this phase, you can still develop new features for the next version, but do not mix up new features and bug fixes. If you need to work new features, work on develop and commit your changes only to develop. Always commit your fixes to release, and it will be merged back to develop. Again, DO NOT COMMIT YOUR FIXES TO DEVELOP.
There is only two rules you need to follow:
- One commit per bug. Push it to release
- Do not mix bug fixes and new features. Commit new features to develop.
Once everyone follows these rules, all bug fixes will be synchronized when we run:
git merge release/VERSION_NUMBER
(not ready yet)