Git-Workflows

Wie Teams Branches, Reviews und Releases organisieren. Jeder Workflow unten kommt mit seinen Regeln, wie seine Originalquelle sie formuliert, wann er passt, und einem animierten Durchlauf – ausgeführt vom Git-Simulator und mit echtem Git geprüft.

WorkflowLanglebige BranchesSo wird releasedPasst am besten zu
mainmain nach jedem gemergten Pull Request deployenApps mit Continuous Deployment
main, developRelease-Branches, auf main getaggtVersionierte Software, mehrere unterstützte Versionen
main (the trunk)Aus dem Trunk oder einem kurzlebigen Release-BranchCI/CD-Teams, die täglich integrieren
upstream’s mainMaintainer mergen Pull Requests aus ForksOpen Source, Beitragende ohne Schreibrechte

GitHub flow

Ein main-Branch + kurzlebige Branches + Pull Requests

Ein schlanker, Branch-basierter Workflow. Alles in main ist deploybar; jede Änderung entsteht auf einem eigenen, aussagekräftig benannten Branch und wird über einen geprüften Pull Request in main gemergt und dann deployt.

Die Regeln

  1. Alles im main-Branch ist deploybar.
  2. Lege für jede Änderung einen aussagekräftig benannten Branch von main an.
  3. Committe lokal und pushe regelmäßig auf den gleichnamigen Branch.
  4. Öffne einen Pull Request für Feedback oder wenn der Branch bereit zum Mergen ist.
  5. Nach dem Review in main mergen und den Branch löschen.
  6. Deploye, sobald gemergt ist (im Originalbeitrag: „du kannst und solltest sofort deployen“).

✓ Nutze ihn, wenn

Web-Apps und Dienste, die kontinuierlich aus einer einzigen Version deployt werden.

✗ Vermeide ihn, wenn

Du musst mehrere veröffentlichte Versionen parallel pflegen.

Quellen

Öffnen und Mergen des Pull Requests passieren auf GitHub; der Durchlauf zeigt die entsprechenden Git-Operationen (GitHubs Standard-Merge-Button erzeugt einen Merge-Commit).

Richte den Workflow ein und geh ihn einmal durch.

DEINE DATEIEN – EINE DATEI, DREI ORTEArbeitsverz.FestplatteStagingnächster CommitHEADletzter Commitadd ›commit ›GITUALIZE☁ ORIGIN – github.com/acme/shop (ein anderes Repository)DEIN REPOSITORY – .git auf deinem Laptop2e039acAdd homepage2e039ac897849007af489a58ee9eec107a21974e Add homepageb272b3aSet up projectb272b3abaca08f2f1c56c0562679f66a61035535 Set up project129c2dbInitial commit129c2db06bfe68f8469dc82e6e05d1c03d1f768c Initial commit2e039acAdd homepage2e039ac897849007af489a58ee9eec107a21974e Add homepageb272b3aSet up projectb272b3abaca08f2f1c56c0562679f66a61035535 Set up project129c2dbInitial commit129c2db06bfe68f8469dc82e6e05d1c03d1f768c Initial commitmainmain: ein verschiebbares Label auf einem Commitorigin/mainorigin/main: dein LOKALES Lesezeichen, wo origins Branch bei deinem letzten Fetch/Push standHEADHEAD → der Branch, auf dem du bistmainmain: so, wie er AUF origin existiertREADME.mdunverändertapp.jsunverändertindex.htmlunverändertv1v1v1v1v1v1v2v2v2HEAD → main → 2e039ac “Add homepage”
0.0s / 142s
CommitRing = der Commit, auf dem HEAD stehtnicht erreichbar (existiert noch)Branch = verschiebbares Labelorigin/* = dein Lesezeichen des RemotesHEAD = wo du gerade bist

  1. 1 Einen Branch anlegen

  2. 2 Änderungen machen

  3. 3 Einen Pull Request erstellen

  4. 4 Review-Kommentare umsetzen

  5. 5 Deinen Pull Request mergen

  6. 6 Deinen Branch löschen