Probieren Sie GitHub-PRs per Cherry-Pick aus

 (github.com/134130)
11 Punkte von a1eng0 2024-12-25 | 4 Kommentare | Auf WhatsApp teilen
  • Seit 4 Monaten wird intern ein Mono-Repository verwendet
  • Mit einem Mono-Repository wird auch das häufig damit verbundene Konzept trunk-based development eingesetzt
  • Entsprechend der trunk-based-development-Strategie werden Commits auf den main-Branch gemacht und anschließend per Cherry-Pick in den Release-Branch übernommen
  • Auf Basis des Artikels im LinkedIn-Tech-Blog wurde eine GitHub Action eingerichtet, sie kann CONFLICTs jedoch nicht automatisch auflösen. Wenn ein CONFLICT auftritt, muss der Nutzer den Befehl git cherry-pick lokal selbst ausführen
  • Dafür wurde ein eigenes gh-Plugin entwickelt, das diesen cherry-pick-Befehl unterstützt.

Verwendung

gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]
  • Über die Option -merge lässt sich auswählen, ob der Merge-Commit des PR per Cherry-Pick übernommen werden soll oder die ursprünglichen Commits des PR
    • Wenn nichts angegeben wird oder die Option -merge=auto verwendet wird, wird die beim PR verwendete Merge-Strategie automatisch erkannt und angewendet
  • Über die Option -push wird nach erfolgreichem Cherry-Pick ein automatischer Push ins Remote-Repository unterstützt

Rückblick

  • Beim Entwickeln eines Programms, das fortlaufend mit externen Prozessen und Zuständen interagiert, wurde ein separates Test-Repository erstellt, um ein Test-Dataset zu erzeugen
  • Verschiedene Lernschritte zur Verbesserung der CLI-Erfahrung
    • Das Lernen mit dem Ziel, docker-cli eigenständig nachzubauen, war hilfreich
  • Der Bau eines CLI-Programms erfordert deutlich mehr Aufwand als gedacht
    • viele Statuswerte in einer Pipeline-ähnlichen Form zu verwalten
    • dem Nutzer eine intuitive Input-Schnittstelle bereitzustellen
    • Input-Validierung möglichst früh bereitzustellen
    • das System des Nutzers wieder in den Ursprungszustand zurückzuversetzen usw.
    • Es wurde erwartet, dass sich das in etwa einem Tag umsetzen lässt, tatsächlich dauerte es rund 5 Tage (parallel lief zwar auch die Verbesserung des GitHub-Actions-Workflows, dennoch war der Zeitaufwand deutlich höher als erwartet)

Verwandte Beiträge

4 Kommentare

 
qncnxnlrla 2025-01-04

Hallo~ wie geht ihr vor, wenn ein in den main-(trunk-)Branch gemergter Commit reverted werden muss?

  • Wenn man auf dem main-Branch revertet, wird das dann auch in den release-Branch gecherry-pickt?
  • Fügt ihr statt revert einfach einen Fix-Commit hinzu?

Wenn sich viele Commits angesammelt haben und dadurch Konflikte entstehen, scheint Cherry-Pick in manchen Fällen schwierig zu sein. Mich würde interessieren, ob ihr Erfahrung mit solchen Fällen habt!
 
a1eng0 2025-01-04

Hallo, vielen Dank für Ihre Antwort!

Wie gehen Sie damit um, wenn ein in den main-(trunk-)Branch gemergter Commit revertiert werden muss?

Im PR zum Revert für den main-Branch geben wir den cherry-pick an. Da im ursprünglichen PR-Link die gesamte cherry-pick-Historie erhalten bleibt, gibt es keine Schwierigkeiten bei der Nachverfolgung. Zusätzliche mechanische Checks führen wir nicht durch, haha.

Wenn sich viele Commits angesammelt haben und Konflikte entstehen, kann cherry-pick schwierig werden

Wenn man zunächst einmal trunk-based development praktiziert, ist jeder PR klein, sodass Konflikte nicht häufig auftreten. Falls doch Konflikte entstehen, muss der Code manuell geschrieben werden. Wir releasen sehr häufig und lassen den Support für zu alte Versionen schnell auslaufen, um zu vermeiden, dass sich der Codezustand zu stark verändert.
 
lamanus 2024-12-26

Ich verstehe nicht wirklich, warum diese Strategie nötig ist ...
 
a1eng0 2024-12-26

Wenn Sie den in release-from-trunk vorgestellten Inhalt lesen, hilft das vielleicht beim Verständnis, haha