Branching Strategy

Scenarioo Demo Example Branching Strategy

Since the demo also contains special skeletons and solutions for course or workshop exercises, some special branching strategy and guildelines are important to know and to be followed:

Branches and their purpose

When working on something always consider to do your changes on an appropriate branch:

• develop: for usual improvements of the demo example (applicable for all courses). This is the preferred location for any ongoing development of the demo and course example.

• feature/[feature-name]: usual feature branches, in case you work on some experimental or larger features until those are stabilized and can be merged back to develop.

• course-[course-name]-solution: Each course has a snapshot of the demo as solution, usually realy nothing else than the snapshot, but in case you need to do changes that you NEVER want to merge to the general demo branch, you can commit them here (but this should be only an exceptional case, e.g. for special solution comments or for removing parts not needed in that specific course exercise). This is not recommended, because such changes might become difficult to keep alligned with the full demo code later! Usually the solution should be just a simple snapshot of the develop or master branch without changes. Do your changes to the course on the develop (or special feature branch for the course) and then merge them to this branch and to the skeleton instead!

• course-[course-name]-skeleton: This should basically be the same as the corresponding solution branch but with parts of the code removed and some additional hints as comments. You should only perform a change and commit it here in case you have a change only for the skeleton. Otherwise you must do your change on the other branches and merge it to here.

Merging guidelines

1. NEVER merge from „course-*“ branches to the “develop” or “master” branch (only cherry picking in very exceptional cases is allowed, if you know exactly what you are merging).

2. REGULARLY integrate (=merge) from “develop” to course branches (to be done by course responsibles).

3. ONLY commit directly to course branches when doing something very specific for a course skeleton or solution that you never want to merge to develop/master (e.g. removing some TODOs, additional comments etc.). Not recommended to use for large changes, because difficult to keep alligned with the rest of the example.

3.1. IF NEEDED do your course specific changes allways on the solution branch and then merge from “course--solution” to “course--skeleton" for merging very rare changes that are done only for the course.

3.2. NEVER merge from "course--skeleton" to "course--solution": obviously this will probably remove the removed parts in the skeleton again from the solution, which is not what we want.

Furthermore, the usual branch strategy used on all scenarioo repos is applied, as described here.

Course Maintainance Process

You are maintaining one of the specific course exercise examples, you should work similar to the following working process:

1. Implement any improvements or fixes to the demo tests on branch "develop":

   git checkout develop
   then implement changes and commit
   git push

2. Integrate changes on develop into your course solution:

git checkout course-[course-name]-solution
git merge develop
git push

3. Integrate the changes in solution into the course skeleton:

git checkout course-[course-name]-skeleton
git merge course-[course-name]-solution
manually undo those incoming merged changes you do not want to have in the skeleton branch
commit these "undo changes"
or: you can also use git revert [commit-nr] to exclude a whole merged commit (leads to a reverting commit)
git push