-
Notifications
You must be signed in to change notification settings - Fork 6
Home
Welcome to the graph-dsl wiki! graph-dsl is a quick and easy way to create graphs and perform algorithms on them. It creates a traditional set of vertices and edges and provides a lot of groovy magic to deal with them.
#Status ##Master
##Develop
#Continuous Integration
graph-dsl uses travis-ci to build, test, and run static code analysis for sonarqube.
This project uses gitflow-avh with github pull requests. For these to work together some rules should be followed.
- Pull requests are used to run checks and allow comments. Sonar adds comments for issues it finds.
- If a pull request resolves and issue it should have (resolve #X) to close the issue in github when it is merged.
- For features pull requests should be made against develop.
- For releases and hotfixes pull requests should be made against master.
- Releases should be made for each feature merged. There should only be bug fixes release branch.
- Documentation should be updated to reflect the new release.
- Internal pull requests should not be merged through github.com. Instead, use gitflow to do the merge. Once gitflow merges the branches, github.com should be automatically marked as merged by github.com.
I'm not sure how to handle external pull requests yet.
Features and bug fixes should be released as soon as they are merged to develop. This is so they can be continuously delivered and to make semantic versioning much easier.
git flow release start <new version number>
This creates a release branch from develop. The version number is automatically "bumped" by the gradle git flow plugin: apply plugin: 'com.github.amkay.gitflow'
an example of what the version is
Inferred version 0.2.0-pre.7+sha.22c2439
The version on the release branch is a pre-release. Once git flow release finish
is called it becomes a real release.
Once a release branch is created it should be pushed to github.
git push --set-upstream origin release/0.2.0
This will create the branch on github and push it.
Now a pull request should be created between the release branch and master. This is to review all of the changes before they are finally put into master. It also allows any issues filed to automatically be closed.
The normal gitflow workflow breaks pull requests in github. Here is the workaround.
//use the -k flag to keep the feature branch
git flow feature finish test -k
//after all the merging is done, the PR should be marked as 'merged', so you can delete the remote branch
git flow feature delete test -r