We are using a git-flow with rebase workflow with the following permanent branches:
- the main development (and also default) branch where all feature branches (if any) are to be rebased/merged to and the only branch we accept Pull Requests for
- the release branch
- a branch to trigger Coverity scans
The difference to the original git-flow workflow is that feature branches must be rebased on
develop before merging.
The build procedure is documented in Build Workflow, the actual build of the executables is implemented using Continuous Integration and depends on the proper usage of the git-flow model and the branches mentioned above!
Please note: The reseller configuration data repository has a only single
master branch with no tags.
In addition to the requirements mentioned in Build Workflow#Required tools, you need the following to develop Sepiola (single Pull Requests against the
develop branch can of course be sent directly via GitHub).
- Git (obviously)
- git-flow tools
git clone https://github.com/stepping-stone/sepiola.git cd sepiola git flow init
git flow init use the following settings.
Which branch should be used for bringing forth production releases? - develop Branch name for production releases:  master Which branch should be used for integration of the "next release"? - develop Branch name for "next release" development: [develop] How to name your supporting branch prefixes? Feature branches? [feature/] Bugfix branches? [bugfix/] Release branches? [release/] Hotfix branches? [hotfix/] Support branches? [support/] Version tag prefix?  v Hooks and filters directory? [/home/youruser/yourworkdir/sepiola/.git/hooks]
Developing new features
- clone the Sepiola repository from GitHub, you will automatically get the
- create a new branch:
git checkout -b feature-XYZ
- make commits there:
git commit -m 'wrap tool CoolStuff'and possibly push:
git push -u origin feature-XYZ
- rebase and squash commits:
git rebase --autosquash -i develop
The idea is that each commit does one thing. If you have to fix a commit, use the
git commit --fixup 'old commit' feature (or the
--amend) and the
--autosquash option on rebase as shown above to squash the commits.
git add -i to interactively add portions of a file to a commit instead of the whole file to get connected changes into the same commit.
With the git-flow tools:
git flow feature start XYZ # do the commits and changes here git flow feature finish XYZ
Simple changes can also be committed directly to the
Merging the feature without the git-flow tools to the
develop branch should work as follows (untested):
git checkout develop git pull --rebase git checkout feature-XYZ git rebase develop git checkout develop git merge --no-ff feature-XYZ git push origin develop git branch -d feature-XYZ
Making a release
Following the Git-Flow model, every merge to the
master branch constitutes a release.
With the git-flow tools:
# insert your version for X.Y.Z here git flow release start X.Y.Z # update the version number (CPACK_PACKAGE_VERSION_MAJOR/MINOR/PATCH) in CMakeLists.txt: vim CMakeLists.txt # Check the copyright dates and update if needed # Especially the one displayed in the About-dialog (Translation and dialog file) git commit -m "Bump version to X.Y.Z." CMakeLists.txt git flow release finish X.Y.Z # In the second editor window which is supposed to appear, there should be no comment. # In that window you are supposed some short description on the first line and optionally some longer description starting at the third line, like so: # Grand new release # # includes new feature X # and new feature Y git push --all --follow-tags
Making the release manually without the git-flow tools should work as follows (untested):
- first create a release branch
release-X.Y.Zbased on the
- update the version number (
- commit it:
git commit -m "Bump version to X.Y.Z." CMakeLists.txt
- get the master branch:
git checkout master
- merge the release branch:
git merge --no-ff release-XYZ
- tag the release:
git tag -a -m "Version X.Y.Z" vX.Y.Z
- merge back the master branch to the develop:
git checkout develop; git merge --no-ff master</code>
- push everything:
git push --all --follow-tags
Submit to Coverity
We have a Coverity account for Sepiola. The scanning is currently based on builds done by Travis CI when pushing to the
coverity_scan branch, therefore it is terribly easy to submit new builds (please note: there is a limit of ~ 5 scans per day per project):
git clone https://github.com/stepping-stone/sepiola cd sepiola git checkout coverity_scan git merge --no-ff develop git push
The scan is currently done for the Linux 64bit version only.