-
Notifications
You must be signed in to change notification settings - Fork 6
Workflow
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.
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
Features should be created to implement new api changes. The changes should be limited in scope and specified in a issue on github. This is to help facilitate continuous delivery of features.
git flow feature start <name>
This will start a feature. The name should limit the scope of what api changes are made. Once a feature is created it is a good idea to push the branch to github.
git push --set-upstream origin <name>
A pull request should be created to compare the feature branch to develop. This will start the code review process and allow all automated checks to be performed against the changes for each push. When the feature is complete it should be merged back into develop with the finish command. The -k option is used so the pull request can show as merged rather than closed in github.
git flow feature finish <name> -k
git flow will switch to develop and merge the feature. Do not push develop right away. Instead, create a release so we only release this new feature.
git flow release start <version>
Develop still needs to be pushed to github. It may be good to just push everything now.
git push --all
This should change the merge request to the merged status.
Once the feature is finished and pushed to github delete the branch.
git flow feature delete <name> -r
Continue with the release.
bugfix branches are exactly like feature branches except they address a bug.
git flow bugfix start <name>
git push --set-upstream origin <name>
git flow bugfix finish <name> -k
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 <semantic version>
Pick <semantic version> according to semantic versioning. Bugs should increment the 3rd digit. If a feature make breaking changes increment the major version if not increment the minor version.
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.
Perform all actions needed to complete the release. There should be very little coding since the feature should already work. Fixing minor bugs is ok though.
It is important to remember to update the README.md file with release information. Also ensure any changes to the usage section are made.
Once the release is ready complete it. Use -k to make sure the release branch can be pushed which merges the pull request.
git flow release finish <semantic version> -k
Make sure all branches and tags are pushed to github.
git push --tags
git push --all
This should result in the pull request being merged and a release being added to github. Delete the release branch.
git flow release delete <semantic version> -r
Edit the release in github updating it with release notes. If it is a pre-release mark it in github.