|
@ -530,7 +530,39 @@ Ein Singleton ist ein Objekt einer Klasse welches genau einmal zur Runtime läuf |
|
|
- _sammelt_ Änderungen |
|
|
- _sammelt_ Änderungen |
|
|
- werden bei Bedarf mit einem Commit gepusht |
|
|
- werden bei Bedarf mit einem Commit gepusht |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- So funktionieren Branches innerhalb von SCM-Systemen |
|
|
|
|
|
|
|
|
|
|
|
- Master-/Defaultbranch |
|
|
|
|
|
- ist immer vorhanden |
|
|
|
|
|
- nur bestimme Personen sollten das Recht haben auf den Branch commiten zu dürfen |
|
|
|
|
|
- geht an Kunden |
|
|
|
|
|
- daher Versionsnummer |
|
|
|
|
|
- sollte nicht manuel germerged werden |
|
|
|
|
|
- sondern über CIS |
|
|
|
|
|
- überprüft Code |
|
|
|
|
|
|
|
|
|
|
|
- Developmentbranch |
|
|
|
|
|
- auch immer vorhanden |
|
|
|
|
|
- gleicher Startpunkt wie Master |
|
|
|
|
|
- alles sollte _lieferbar_/_shipable_ sein |
|
|
|
|
|
- da neue Features gesammt werden |
|
|
|
|
|
- die dann am Ende eines _Sprints_ |
|
|
|
|
|
- eine neue Version im Masterbranch ergeben |
|
|
|
|
|
- jeder Entwickler darf Features reinmergen |
|
|
|
|
|
- sollen aber Pullrequests geschehen |
|
|
|
|
|
- CIS-System überprüft und bei Erfolg merged |
|
|
|
|
|
|
|
|
|
|
|
- Releasebranch |
|
|
|
|
|
- Abzweigung von Developmentbranch |
|
|
|
|
|
- nur noch Fixes |
|
|
|
|
|
- keine neuen Features |
|
|
|
|
|
- jeder kann commiten |
|
|
|
|
|
- jeder Commit hat eine Tag der den Teilstring _release candidate_ enthält |
|
|
|
|
|
- Zuordnung von Fehlern zu bestimmten Ständen |
|
|
|
|
|
- Am Ende des Releasebranches |
|
|
|
|
|
- Release erzeugt |
|
|
|
|
|
- commit aus Release- in Masterbranch |
|
|
|
|
|
- Fixes aus Releasebranch werden auch zurück in Developmentbranch gemerged |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|