Development Workflow

From Sepiola Wiki
Jump to: navigation, search



We are using Git with the main repository on GitHub. There is also a secondary private repository for the reseller configuration and data (urls, artwork, etc.).

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.

Required tools

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).

Initial checkout

git clone
cd sepiola
git flow init

For 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 develop branch
  • 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.

Also use 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 develop branch.

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.Z based on the develop
  • update the version number (CPACK_PACKAGE_VERSION_MAJOR/MINOR/PATCH) in CMakeLists.txt
  • 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
cd sepiola
git checkout coverity_scan
git merge --no-ff develop
git push

The scan is currently done for the Linux 64bit version only.

Personal tools