iteration of branching convention

[AlexHentschel]

We have struggled with our branching convention in the past, in that engineers had difficulties to fully internalize it. Furthermore, similar questions as to why the convention is the way it is and proposals for modifications were repeatedly brought up over the years, because we haven't documented motivations and reasoning for the convention. Discussing proposed changes to the branching strategy is usually very resource intensive, because we require a larger cross-section of the engineering team to be present in those discussions including the most senior engineers. My impression is that the majority of time in those discussions, we spend on going over the same arguments again, and clarifying the same questions.

Therefore, I think it is important to provide a high-level intuitive picture of our branching strategy and connect it to broadly-used concepts that most engineers are very familiar (deployment branches, feature branches, master). In addition, a motivation and briefly addressing repeatedly-suggested alternatives (such as having only a single long-living spork instead of many feature branches) will help engineers to better internalize our convention, simplify onboarding, and hopefully reduce time spent on in-person discussions of possible modifications of the branching strategy.

Overview of this PR

This PR is an extension of PR #6162:

• further detailing the specification of the branching convention
• adding illustration for clarity
• providing a context what specific scenarios the different aspects of the branching convention are addressing
• adding motivations and reasoning why the branching strategy is the way it is