•  11-09-2019
  •  | 
  •  

Frage

Ich habe gerade angefangen Git neben Mercurial mit mir mit Git vertraut zu machen.

Ich verwende die mq Erweiterung in Mercurial ausgiebig lokalen Patches zu verwalten, und ich bin für einen Git äquivalent suchen.

Soll ich nur Git-Zweigs verwenden? Oder gibt es bessere Möglichkeiten, lokale Patches zu verwalten, die leicht ermöglichen Auftragen und Entfernen der Patches?

Danke,

War es hilfreich?

Lösung

Check out "Patch-Management-Interface-Schichten" Abschnitt Interfaces, Frontends und Werkzeuge Seite auf Git Wiki. Es gibt zwei Patch-Management-Schnittstellen aufgeführt, entspricht in etwa Merkurialien 'mq' Erweiterung :

  • stgit (Stacked Git), ältere der beiden, in Python geschrieben, verwendet zwei Snapshots repräsentieren Patch
  • Schuld (ehemals 'GQ'), als Serie von Bash-Skripte geschrieben, Serie Datei und die Patches (eine pro Datei) als Textdatei gespeichert werden.
  • pg (Patchy Git) ist veraltet , und nicht mehr aufrecht erhalten.

Aber, wenn Sie nicht mehr nutzen Nutzen benötigen, können Sie verwenden, anstatt " git --interactive rebase" neu zu ordnen, Squash und Split-Patches. Und Ihren Zweig gegen aktuelle Version des Upstream „git rebase“ verwalten in der Regel ausreichen würde.

Andere Tipps

Disclaimer: Ich bin kein hg Benutzer, so habe ich über hg lesen, aber haben nicht viel Erfahrung aus erster Hand es mit

.

git bietet einige sehr leistungsfähige und flexible Werkzeuge für die Zweige in einem ‚Patch-Warteschlange‘ Stil der Verwaltung so für viele einfach (und sogar einige sehr komplex) verwenden Fällen nativen git ausreichend leistungsfähig ist.

Normalerweise sind die meisten Projekte halten einen zentralen stabilen Master Zweig, der nur neue Commits gewinnt und wird nie ‚zurückgespult‘ begeht so in dem Master-Zweig sind festgelegt.

Auf diesem Maintainer (oder einen Entwickler) eine beibehalten oder mehr Fluidzweige work-in-progress-Patches (d begeht), die auf dem stabilen Ast basieren.

Typische Patch Verwaltung Aktivitäten umfassen:

Rebasing die Patch-Queue auf die neuesten stabilen Zweig - Verwendung git rebase,

Duplizieren der Patch-Warteschlange auf einen alten maintentance Zweig - Verwendung git branch und git rebase,

Nachbestellung von Patches in der Warteschlange -. Verwendung git rebase --interactive (aka git rebase -i) mit einem Texteditor die Warteschlange neu zu ordnen

Quetschen Patches - Verwendung git rebase -i mit der Squash-Richtlinie

Ändern Patches oder Patch-Commit-Nachrichten -. Verwendung git rebase -i (? Ein Thema vor Ort) mit der Bearbeitungs Richtlinie

Jede Aktivität, die einen Patch in irgendeiner Weise verändert (das heißt sein Inhalt, Beschreibung oder Abstammungs) wird ein neues begeht mit einer neuen begeht ID für diesen Patch erstellen. Die Tatsache, dass die alten Commits weggeworfen werden können und regelmäßig ausgetauscht, bevor sie in dem stabilen Hauptzweig gefördert werden, ist das einzige, was sie eine ‚Patch-Warteschlange‘ und nicht als ein Zweig macht, aber dies ist ein Projekt Konvention eher als jeder körperlichen Unterschied in den Daten, die die Commits bilden. Git sie sind identische Objekte.

Um einen Patch zu einem ‚echten‘ zu fördern verpflichten nur wird das Pflaster auf die Vorderseite der Warteschlange bewegt und es in den Hauptzweig zu verschmelzen. Nach der Bewegung, den Patch an die Vorderseite der Warteschlange ist es genau das gleiche wie ein normales commit basierend auf dem Hauptzweig, so dass es nur spult den Master Verzweigungszeigerarm verschmelzenden an dem Patch COMMIT-Punkt.

Die Veröffentlichung dieses als ‚stabil‘ Master Patch zu begehen ist der Akt, der sagt: Dies ist ein jetzt verpflichten, dass nicht ändern wird und ein Teil der unveränderlichen Geschichte des Projektes ist

.

Sie einfach einen Zweig verwenden und gegen Upstream Zweig regelmäßig rebase. Dies ist sowohl einfacher zu verwalten und sicherer als mq mit (zu denen ich in der Vergangenheit verloren gegangene Daten).

Git bietet nicht wirklich diese Funktion selbst. Je nach Ihren Anwendungen, können Sie möglicherweise mit „Git Stash“ erhalten, indem Sie und / oder Zweig, aber es wird ziemlich einfach sein. Wenn die Menschen mehr erweiterte Patch-Management mit git benötigt haben, scheinen sie zu drehen steppen oder stgit: siehe http: // git.or.cz/gitwiki/PatchManagement

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top