Was ist "Vendoring"?

Vendoring ist eine Möglichkeit, die Arbeit anderer in Ihre eigene zu integrieren. Es ist das Gegenteil von "Verknüpfen" mit Bibliotheken von Drittanbietern. Anstatt diese Bibliothek als Abhängigkeit zu haben, verwendet die Anwendung diese Bibliothek als Teil des eigenen Quellcodes und behält diesen Code in sich.

Normalerweise erfolgt der Verkauf über Sprachwerkzeuge: Bündler, Fracht, Pip usw. Aber manchmal müssen Sie etwas anbieten, das von keinem vorhandenen Toolset abgedeckt wird, oder etwas Mehrsprachiges, damit es unmöglich ist, das 'Kern'-Sprachwerkzeug dafür zu finden.

Die Lösung für diese Situation ist das Vendoring auf Git-Ebene. Sie haben Ihr eigenes Git-Repository (ich nenne es " Ziel-Repo ") und möchten ein anderes Repository (ich nenne es " Quell-Repo ") als Verzeichnis in Ihr (Ziel-Repo) integrieren.

Die Dinge, die Sie von einem gut gestalteten Verkaufssystem erwarten (unabhängig davon, ob Git es ist oder nicht):

Sichtbarkeit Sie möchten wissen, dass ein Code verkauft wird, dh er wurde nicht vom Committer geschrieben.
Provenienz Sie möchten wissen, woher es kommt. Was war das Repository, das jemand vor zwei Jahren in Ihr Repo integriert hatte? Und welche Version / Commit war?
Aktualisierbarkeit Sie möchten diesen Code aktualisieren können, wenn ein Fehler im ursprünglichen Repo behoben wurde (oder eine neue Funktion mit langer Wartezeit vorhanden ist). Als Sonderfall für die Aktualisierbarkeit möchten Sie in der Lage sein, verkauften Code (und nur diesen) zu löschen.
Wiederholbarkeit Vendoring sollte nicht die Kunst sein, es sollte der starre fehlerfreie Prozess sein. Vendor Foo in Bar sollte das gleiche Ergebnis liefern, egal wer es getan hat.
Transportierbarkeit. Eine Person, die Ihr Repository klont, sollte in der Lage sein, den Verkauf genauso wie Sie fortzusetzen. Das bedeutet, dass alle Vendoring-bezogenen Informationen im Git bleiben und während des Push / Pull übertragen werden sollten.
Governance. Alle verkauften Änderungen sollten so bleiben, wie sie sind, bis jemand sie aktualisiert. Sie möchten keine unerwarteten (aktuellen) Updates haben, außerdem möchten Sie unbedingt verkaufte Inhalte verfügbar halten, auch wenn das Quell-Repo nicht mehr verfügbar ist.
Patchbarkeit. Sie möchten in der Lage sein, den verkauften Code zu optimieren und ihn dennoch auf eine neuere Version zu aktualisieren. Am besten ohne Konflikte, aber zumindest mit klarer Sichtbarkeit, wo diese Konflikte aufgetreten waren.

Und angesichts der Git-Natur von Git möchten Sie, dass dieses System branchenfreundlich ist. Wenn Zweig A Code in Version a1 und Zweig B in Version b1 verkauft hat, möchten Sie jedes Mal zwischen ihnen wechseln, wenn Sie zwischen A und B wechseln. Außerdem möchten Sie in der Lage sein, Version a1 in a2 und Version b1 in zu ändern b2 ohne Sorgen um Versionen in einem anderen Zweig.

... und Sie möchten in der Lage sein, mehr als ein externes Repository bereitzustellen, sodass Vendoring kein einmaliges Ereignis pro Repo sein sollte.

Wie Sie sehen, ist es eine lange Liste von Anforderungen. Ich habe vorhandene (andere) Lösungen analysiert, bevor ich zur besten Lösung (Git-Anbieter) gelangt bin.

Kopieren Einfügen

Copy-Paste ist eine so bösartige Art, etwas zu verkaufen, dass ich nichts Gutes dazu zu sagen habe. Sie verlieren Herkunft, Sichtbarkeit, Aktualisierbarkeit. Sie verlieren jedoch nicht die Transportfähigkeit, da es überhaupt keine Verbindung zum alten Repo gibt. Mach kein solches Vendoring.

Git-in-Git

Dies ist ein dummer, aber etwas funktionierender Trick. Erstellen Sie einen Ordner vendored_foobar in Ihrem Repository, gehen Sie zu vendored_foobar und klonen Sie diese foobar. Kehren Sie zur obersten Ebene zurück und übernehmen Sie alle Änderungen, die Sie vorgenommen haben.

Vorteile: Einfach zu erledigen, lokale Herkunft, Governance und eine hervorragende Patchablity.

Nachteile: Es ist spröde, es überlebt Push nicht (verschachtelter .git-Ordner ist nicht in Ihrem Repo enthalten, daher ist für externe Beobachter der verkaufte Code nicht von Ihrem eigenen zu unterscheiden). So verlieren Sie auf lange Sicht die Transportfähigkeit und die Herkunft.

Submodule

Die Idee ist, dass Sie einige Ordner Ihres Git in einem anderen Git verwaltet haben. Es ist das älteste "Etwas", das Git zur Verfügung gestellt hat. Leider ist es branchenunfreundlich und es fehlt die Kontrolle über den verkauften Code. Wenn Remote Repo weg ist, können Sie Ihre Submodule nicht verwenden.

Und vergessen Sie nicht, wie schwer es ist, dieses Repo zu klonen.

Git Teilbaum

Git kann die Teilbaummethode verwenden, um externe Git als Ordner in das lokale Git-Repository zusammenzuführen. Es ist fast perfekt, abgesehen von Aktualisierbarkeit, Wiederholbarkeit, Herkunft und Sichtbarkeit. Wenn man nicht manuell in eine Git-Geschichte eintaucht, ist es unmöglich zu sehen, welcher Teil des Git-Repos verkauft wird und welcher nicht. Und Sie haben keine Ahnung, woher diese Änderungen kommen. Wenn der Committer dies nicht geschrieben hat, gehen Informationen verloren. Und wenn ja, ist dies nicht wiederholbar, da beim Ausfüllen dieser Informationen geringfügige Änderungen auftreten können.

Geben Sie also den preisgekrönten Gewinner, den Git-Anbieter, ein.

Git-Anbieter

Git Vendor ist eine erstaunliche Erweiterung für Git, die Brett Langdon vor etwa drei Jahren geschrieben hat. Es sind nur etwa 200 Zeilen in Bash, aber es ist so gut geschrieben, dass ich mich überhaupt nicht darüber beschwere (es enthält alles, was ein gutes Programm haben sollte: Handbuchseiten, Hilfe, Bash-Abschluss, angemessene Fehlerbehandlung und ausfallsichere Schutzmaßnahmen).

Es verwendet den Git-Teilbaum und erweitert ihn um Funktionen, um lose Seiten des Verkaufs durch den Git-Teilbaum abzudecken.

Jeder wichtige Punkt wird überprüft:

Visilibity. Rufen Sie einfach die git vendor list und sehen Sie sich alle verkauften Artikel an.
Herkunft. Es zeigt Remote Repo und zeigt an, welches Commit verkauft wurde.
Aktualisierbarkeit. git vendor update , und es unterstützt für Zweige, Tags und Commits, um genau zu bestimmen, was genau zu nehmen ist. Und Sie können natürlich git vendor remove .
Wiederholbarkeit. Es sind keine manuellen Vorgänge erforderlich, sodass jeder beim ersten Verkauf oder nach Updates das gleiche Ergebnis erzielt.
Transportierbarkeit. Alle Änderungen werden als spezielle Tags in der Git-Historie gespeichert, sodass sie vollständig Push / Pull-freundlich sind. Und sie eignen sich hervorragend für Zweige und beliebige Verlaufskassen.
Regierung. Der gesamte verkaufte Code wird in Ihrem Repo gespeichert.
Patchbarkeit. Es ist (Sie werden einen klaren Zusammenführungskonflikt mit Ihren Änderungen sehen), aber es ist die schwächste Seite des Git-Anbieters. Ich würde es vorziehen, eine 'Patch-Warteschlange' zu haben (wie in debian / pathes für deb-Pakete), aber es gibt trotzdem eine minimale Unterstützung dafür.

Es gibt spezielle Richtlinien für die Art und Weise, wie Inhalte verkauft werden: Wenn Sie https://github.com/serverscom/dibctl klonen möchten, gehen Sie zu vendor/github.com/serverscom/dibctl/ . Sie können den Teil " vendor/ " ändern, der Rest ist jedoch eine harte Richtlinie. Symlinks können dies jedoch vereinfachen.

Es gibt dort nur wenige kleinere Fehler: Sie können es nicht für leere Repos verwenden, Sie können keine lokalen Git als Quellen verwenden, Sie können keine Hilfe sehen, bis Sie im Git-Repo sind. Keiner von ihnen verursacht Probleme bei der normalen Arbeit mit echten Repos.

Fazit

Git-Vendor ist ein perfektes Tool, um ein Git-Repo in ein anderes zu verkaufen. Es bietet alle erforderlichen Funktionen für die Best Practices des Verkaufs: Herkunft behalten, Sichtbarkeit und Aktualisierbarkeit gewährleisten.

Wie man einen Git in einen anderen Git verkauft