Skip to content

workflow

robme91 edited this page Nov 12, 2014 · 3 revisions

Git - 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.

Master und Develop Branch

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 status
  • git 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>

Feature Branches

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 master
  • git merge issue-#001
  • git 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

Generelles

Technologien / Tools

meteor

Lösungen

etc

Sprints

Clone this wiki locally