Benutzer-Werkzeuge

Webseiten-Werkzeuge


Übersetzungen dieser Seite:

Sidebar

Hauptmenü

(oSP 12.11-hiccup.8)
 [[entwicklung:meta:myworkflow]] 

Workflow Prinzip

Dieses Prinit geht auf das Branching Modell GitHub Flow zurück.

  • Es gibt mehrere Branches (möglichst wenige, 1-2) die wie Distributionen heißen: lenny, precise, … (Sie werden remote getracked → auf github sichtbar)
  • Bei den Distributions-Branches gibt es einen oldstable (wird noch versorgt) und einen stable (momentan aktuelle Version) evtl. noch 1-2 testing/experimental
  • Die Distributions-Branches oldstable und stable sind jederzeit deployable (als Debian-Paket auslieferbar). Nach jedem Bugfix wird per Paket-Repository ausgeliefert (deployed).
  • Das Erstellen eines Pakets wird so gescripted, dass es wirklich einfach von jedem user durchzuführen ist. (Anleitung in debian/README.linuxmuster)
  • Es gibt keinen Unterschied zwischen Hotfixes und kleinen Features (macht Vorgehensweise einfacher)
  • Für neue Features wird der Distributions-Branch geforked, auf dem das Feature getestet wird (meist stable). Name des Feature-Branches ist z.B. Bugfix-#42, Feature-#46. Dieser Branch wird lokal angelegt und nach github unter demselben Namen gepushed. Dorthin wird im Laufe der Entwicklung regelmäßig gepushed.
  • Wenn der Bugfix/das Feature auslieferbar/fertig ist:
    • Auf github werden Pull-requests in die beiden (oder mehr) Distributions-Branches abgesetzt. Ein anderer Entwickler merged.
    • Alternativ dazu merged der Hauptentwickler ohne Überprüfiung in die jeweiligen Distributions-Branches.
    • Wird der Branch oldstable nicht mehr gebraucht, liegt er noch eine Weile rum, bis es gelöscht/archviert wird.

Einmalig eigene Branches für den Workflow einrichten

Startpunkt: fast leeres, auf github angelegtes Repo mit Branch master

git clone github:jeffbeck/jeffbeck-test-without-hubflow

Distributions-Branches anlegen:

git branch precise
git branch lenny
git branch quantal
git branch raring

Nun liegen verschiedene lokale Branches vor.

Branches remote pushen:

git push origin quantal
...

Die Distributions-Branches sind nun auf github sichtbar.

Änderungen z.B. in lenny vornehmen und pushen.

git checkout lenny
... edit ...
git add .
git commit -m "Created on branch lenny"
git push

.

Workflow in geclontem Repo nutzen

Wenn man keinen Schreibzugriff ins Originalrepo hat, muss es zuerst via github zu sich geclont.

git clone github:jeffbeck/jeffbeck-test-without-hubflow

Lokal gibt es dann erstmal nur den Branch master:

git branch

Die anderen Branches sind nur remote:

git branch -r
git remote show origin

Diese remoten Branches auschecken und tracken:

git checkout --track -b precise origin/precise
...

Nochmal checken ob die Branches da sind:

git remote show origin

Wenn es remote auf einem dieser getrackten Branches (z.B. lenny) Änderungen gibt, werden diese so geholt:

git pull --all
git checkout lenny
git pull

Es scheint kein Befehl zu geben, der alle remotes auf einmal holt.

Feature in ''quantal'' lokal fixen und in mehrere Branches mergen:

Branch ''Bugfix1'' erstellen

git checkout quantal

git pull
git branch Bugfix1
git checkout Bugfix1
... fix the bug ...
git add .
git commit -m "Bugfix1"
git push

git push legt den Branch Bugfix1 NICHT auf github

Möglichkeit A) Diesen Branch Bugfix1 lokal in mehrere Branches mergen (lenny, precise)

Welche Branches sind schon auf den momentan benutzten Branch gemerged?

git branch --merged

Welche Branches sind (noch) NICHT auf den momentan benutzten Branch gemerged?

git branch --no-merged

Nun einen noch nicht gemergden Branch mergen:

git checkout lenny
git merge Bugfix1
git push

git checkout precise
git merge Bugfix1
git push

In den merge Meldungen steht dann Merge branch „Bugfix1“ into precise

Möglichkeit B) Diesen Branch Bugfix1 auf github mit Pull-Requests in mehrere Branches mergen (lenny, precise)

Den Branch Bugfix1 auf github pushen:

git push origin Bugfix1

Dort pull Requests absetzen:

  • precise ← Bugfix1
  • lenny ← Bugfix1

Pull Requests mergen (Hauptentwickler)

  • Pull Request 1 mergen (Bugfix1-Branch NICHT löschen)
  • Pull Request 2 mergen (Bugfix1-Branch löschen)

In den merge Meldungen steht

  • Merge pull request #1 from jeffbeck/Bugfix2
  • Merge pull request #2 from jeffbeck/Bugfix2

Möglichkeit C) Pull Requests aus anderem Repo

Falls man das Repo zu sich geclont hat, stellt man den Pull-Request wie bei B), jedoch an das Original-Repo.

Dies wird von github automatisch vorgeschlagen, da das Repo weiss, woher es geclont wird.

Todo: Tools zur Erweiterung

linuxmuster-source könnte folgende funktionalität mit dem Befehl lms haben:

  • lms update (holt alle Branches)
  • lms startfix Bugfix1 (legt den Branch Bugfix1 lokal und auf github an)
  • lms merge lenny,precise Bugfix1
    • geht in Branch lenny
    • aktualisiert den Branch
    • merged den Bugfix1 Branch
    • entfernt den Bugfix-Branch wieder
  • … usw …
 [[entwicklung:meta:myworkflow]] entwicklung/meta/myworkflow.txt · Zuletzt geändert: 2013/03/08 00:42 von jeffbeck