-
Notifications
You must be signed in to change notification settings - Fork 1
workflow
Das soll eine Schablone für unseren Workflow sein. Anhand von Codebeispielen und Bildern, soll jeder die Übersicht behalten wo er sich grade befindet bzw. wo er sein Code hinpusht etc.
All Copyrights of the following pictures by Workflow|Atlassian
###Hauptbranches
In die Master Branch wird nur Code gepusht der fertig für eine Sprint Abgabe ist. Nichts anderes. Ist ein Sprint fertig wird er getaggt mit der entsprechenden Sprint Nummer. Die Develop Branch ist ein Integrations Zweig für alle Features. Das bedeutet, ist eine Feature fertig wird es auf die Develop Branch gepusht. Mehrere Features ergeben ja dann wieder einen Sprint.
Um die Develop Branch einzurichten wird folgendes getan: - einer der Entwickler erstellt die Develop Branch lokal und pusht sie dann ins GitHub: - git branch develop - git push -u origin develop - alle anderen klonen das repo und sollten damit dann diese Basic Struktur auch lokal auf Ihrem Rechner haben: - git clone ssh://user@host/path/to/repo.git - git checkout -b develop origin/develop
###Feature Branches
Wenn man nun ein neues Feature entwickeln möchte, erstellt man sich eine eigene Branch für dieses Feature und lässt es auf der develop branch basieren: - git checkout -b some-feature develop
Es kann also ganz normal auf dieser Branch entwickelt werden:
git statusgit add <some-file>git commit
Ein Branch ist nicht für andere verfügbar, bis du diesen in dein entferntes Repository hochlädst:
git push origin <branch>
Ist das Feature fertig, sollte es in die develop Branch gemerged werden: - git pull origin develop
-
git checkout develop-git merge some-feature-git push-git branch -d some-feature
Es sollte nie direkt gemerged werden, damit Fehler vermieden werden. Außerdem sollte nie direkt in unsere Sprint/Master Branch gemerged werden, um dort unreinheiten zu vermeiden. Sollte es dennoch zu Merge Problemen kommen hier ein paar Tipps zur Fehlerbehebung.
###Sprint releasen
Ist nun ein Sprint in der Endphase kann eine weitere branch als buffer vor der master branch erzeugt werden. Um final zu dokumentieren oder bugfix zu betreiben o.ä. Alles was in dieser release branch enthalten ist, wird letzendlich als Sprint abgegeben. Hier werden also die letzten Schliffe getan und dann wird wie folgt die release branch auf unsere Master(bzw. Sprint/Abgabe branch) gemerged. - git checkout master - git merge release-0.1 - git push - git checkout develop - git merge release-0.1 - git push - git branch -d release-0.1
Alle bugfixes und documentations müssen natürlich dann auch in der develop branch wieder den neusten Stand erhalten, deshalb dieser Schritt.
Haben wir etwas in unsere Master Branch gepusht sollten wir dies taggen: - git tag -a 0.1 -m "Initial public release" master - git push --tags
###Hotfix in der Sprint/Master Branch
Gibt es nach Vollendung eines Sprints z.B. bei der Präsi oder danach beim TEsten einen Fehler kann man eine Hotfix Branch erstellen und diese direkt dann wieder in den Master Zweig pushen. - git checkout -b issue-#001 master - # Fix the bug
git checkout mastergit merge issue-#001git push
Dieser Hotfix muss dann natürlich auch in der develop Branch stehen: - git checkout develop - git merge issue-#001 - git push - git branch -d issue-#001
- Codestyle
- ScrumPrimer
- Git - Workflow
- Git Magic
-
[[Ordner Struktur]] -
[[Entwicklungsumgebung]] -
[[Definition of Done|dod]]