This page describes the general GIT wrokflow for APP and LSA development (DRAFT)

Legend:

• wihte dot: previous history /master / svn trunk), this point is also called merge-base
• red lines: release branch
• blue lines: int branch
• green lines: master branch
• black lines: feature or bugfix branches
• dark green lines: merges
• red dots: changes on release branch (merges or hotfixes only)
• bluw dots: changes on INT branch (merges only)
• gray dot: changes on bugfix branches (commits from developers)
• black dots: changes on feature branches (commits from developers or merges)

Description

The image above rougly describes the GIT workflow for APP and LSA.

The merge-base can be determined by using the git command git merge-base origin/master origin/int origin/R14. From here we start our current release cycle. The merge base might also change during a release cycle, e.g. when a bug is fixed and merged back to RELEASE, INT and master.

Therefore one can create muldiple independend feature branches and develop on these branches withoud interfering with other developers or users of the artifact.

When a feature is finished, one can provide a snapshot for testing on the playground web location, e.g. by calling mvn clean install on the command line and copying the target to /common/usr/cscoap/htdocs/playgorund/$USERNAME/. After the feature is tested and accepted by the product owner, it can be merged back to master and INT (see Feature/X in the image). If a feature spans the point where another feature is finished and merged into master, it may also be merged into the feature itself to keep API stability during development. If the feature is not finished during one release cycle, the next merge-base has to be merged into the feature, see Feature/Y in the image.

Bugs are also fixed in separate branches and merged back to RELEASE, INT and master, optional to features.

Using this procedure will minimize the merge conflicts for developers and keep the master branches over mulitple repositories / artifacts in a stable version so that everyone can start developing or just using the artifacts for other developments without interfering with other developers.

Lifetime of branches

The master and INT branches will live forever and will continuously be updated. The RELEASE branch will be named like before, e.g. r14, r14_1, and will only life for the current and next release cycle, e.g. when r15 is created, r13 will be deleted. However, the tags contianing the released versions will also be kept forever. The feature and bugfix branches only live until they are merged back to master, INT and probably RELEASE.