Frage Was bedeuten "Zweig", "Tag" und "Stamm" in Subversion-Repositories?


Ich habe diese Wörter viel über Subversion (und ich vermute allgemeine Repository) Diskussionen gesehen. Ich habe SVN in den letzten Jahren für meine Projekte verwendet, aber ich habe nie das komplette Konzept dieser Verzeichnisse verstanden.

Was meinen sie?


1131
2017-08-19 13:22


Ursprung


Antworten:


Hmm, ich bin mir nicht sicher, ob ich der Meinung bin, dass Nick re tag einer Filiale ähnlich ist. Ein Tag ist nur ein Marker

  • Kofferraum wäre der Hauptteil der Entwicklung, die vom Beginn des Projekts bis heute entstanden ist.

  • Ast Es handelt sich um eine Kopie eines Codes, der von einem bestimmten Punkt in der Amtsleitung abgeleitet wurde, der zum Anwenden größerer Änderungen an dem Code verwendet wird, während die Integrität des Codes in der Amtsleitung erhalten bleibt. Wenn die größeren Änderungen nach Plan funktionieren, werden sie normalerweise wieder in den Stamm zusammengeführt.

  • Etikett Es wird ein Zeitpunkt auf dem Stamm oder einem Zweig sein, den Sie bewahren möchten. Die beiden Hauptgründe für die Erhaltung wären, dass es sich entweder um eine Hauptversion der Software handelt, egal ob Alpha, Beta, RC oder RTM, oder dass dies der stabilste Punkt der Software ist, bevor größere Revisionen am Stamm vorgenommen wurden.

In Open-Source-Projekten können wichtige Zweigstellen, die von den Projektbeteiligten nicht in den Stamm aufgenommen werden, die Basis für Gabeln B. völlig getrennte Projekte, die einen gemeinsamen Ursprung mit anderem Quellcode haben.


864
2017-08-19 13:35



Zuallererst, wie @AndrewFinnell und @KenLiu darauf hinweisen, bedeuten in SVN die Verzeichnisnamen selbst nichts - "Stamm, Zweige und Tags" sind einfach eine übliche Konvention, die von den meisten Repositories verwendet wird. Nicht alle Projekte verwenden alle Verzeichnisse (es ist durchaus üblich, überhaupt keine "Tags" zu verwenden), und tatsächlich hält Sie nichts davon ab, sie als etwas zu bezeichnen, das Sie gerne hätten, obwohl das Brechen von Konventionen oft verwirrend ist.

Ich werde das wahrscheinlich gebräuchlichste Anwendungsszenario von Zweigen und Tags beschreiben und ein Beispielszenario ihrer Verwendung geben.

  • Kofferraum: Das Hauptentwicklungsgebiet. Dies ist, wo Ihre nächste Hauptversion des Codes lebt, und im Allgemeinen über die neuesten Funktionen verfügt.

  • GeästJedes Mal, wenn Sie eine Hauptversion veröffentlichen, wird eine Verzweigung erstellt. Auf diese Weise können Sie Fehlerbehebungen vornehmen und eine neue Version erstellen, ohne die neuesten - möglicherweise noch nicht abgeschlossenen oder nicht getesteten - Funktionen freigeben zu müssen.

  • StichworteJedes Mal, wenn Sie eine Version veröffentlichen (Final Release, Release Candidates (RC) und Betas), machen Sie ein Tag dafür. Dadurch erhalten Sie eine Point-in-Time-Kopie des Codes, so wie er in diesem Zustand war. So können Sie zurückgehen und bei Bedarf alle Fehler in einer früheren Version reproduzieren oder eine frühere Version genau so wieder freigeben, wie sie war. Zweige und Tags in SVN sind leichtgewichtig - auf dem Server werden keine vollständigen Kopien der Dateien erstellt, sondern nur ein Marker, der besagt, dass diese Dateien bei dieser Revision kopiert wurden und nur ein paar Bytes benötigen. In diesem Sinne sollten Sie sich nie darum kümmern, ein Tag für einen freigegebenen Code zu erstellen. Wie ich bereits sagte, werden Tags häufig weggelassen und stattdessen wird durch ein Änderungsprotokoll oder ein anderes Dokument die Versionsnummer klargestellt, wenn eine Freigabe erfolgt.


Angenommen, Sie starten ein neues Projekt. Sie beginnen in "trunk" zu arbeiten, was dann als Version 1.0 veröffentlicht wird.

  • Stamm / - Entwicklungsversion, bald 1.0 zu sein
  • Zweige / - leer

Sobald 1.0.0 beendet ist, verzweigen Sie den Stamm in einen neuen Zweig "1.0" und erstellen ein "1.0.0" -Tag. Arbeite nun daran, was im Stamm 1.1 schließlich weitergeht.

  • Stamm / - Entwicklungsversion, bald 1.1
  • Filialen / 1.0 - 1.0.0 Release-Version
  • Tags / 1.0.0 - 1.0.0 Release-Version

Sie stoßen auf einige Fehler im Code und beheben sie im Stamm, und führen Sie dann die Fixes über den Zweig 1.0 zusammen. Sie können auch das Gegenteil tun und die Fehler in der 1.0-Verzweigung beheben und sie dann wieder mit dem Stamm zusammenführen, aber im Allgemeinen bleiben Projekte dabei, nur in eine Richtung zu verschmelzen, um die Chance zu verringern, etwas zu verpassen. Manchmal kann ein Fehler nur in 1.0 behoben werden, da er in 1.1 veraltet ist. Es ist nicht wirklich wichtig: Sie wollen nur sicherstellen, dass Sie 1.1 nicht mit den gleichen Bugs veröffentlichen, die in 1.0 behoben wurden.

  • Stamm / - Entwicklungsversion, bald 1.1
  • Zweige / 1.0 - kommende Version 1.0.1
  • Tags / 1.0.0 - 1.0.0 Release-Version

Sobald Sie genug Bugs gefunden haben (oder vielleicht einen kritischen Bug), entscheiden Sie sich für eine 1.0.1 Veröffentlichung. Sie erstellen also einen Tag "1.0.1" aus dem Zweig 1.0 und geben den Code frei. An diesem Punkt enthält trunk was 1.1 sein wird, und der "1.0" Zweig enthält 1.0.1 Code. Wenn Sie das nächste Mal ein Update auf 1.0 veröffentlichen, wäre es 1.0.2.

  • Stamm / - Entwicklungsversion, bald 1.1
  • Zweige / 1.0 - bevorstehende Version 1.0.2
  • Tags / 1.0.0 - 1.0.0 Release-Version
  • Tags / 1.0.1 - 1.0.1 Release-Version

Schließlich bist du fast bereit, 1.1 zu veröffentlichen, aber du möchtest zuerst eine Beta machen. In diesem Fall erstellen Sie wahrscheinlich einen Zweig "1.1" und einen Tag "1.1beta1". Arbeiten Sie jetzt an der Stelle, an der 1.2 (oder vielleicht 2.0) sein wird, in der Amtsleitung, aber die Arbeit an 1.1 wird im Zweig "1.1" fortgesetzt.

  • Stamm / - Entwicklungsversion, bald 1.2 zu sein
  • Branches / 1.0 - kommende Version 1.0.2
  • Zweigniederlassungen / 1.1 - kommende Version 1.1.0
  • Tags / 1.0.0 - 1.0.0 Release-Version
  • Tags / 1.0.1 - 1.0.1 Release-Version
  • Tags / 1.1 Beta1 - 1.1 Beta 1 Release-Version

Sobald Sie 1.1 final veröffentlichen, machen Sie ein "1.1" -Tag aus dem Zweig "1.1".

Sie können 1.0 auch beibehalten, wenn Sie Bugfixes zwischen allen drei Zweigen (1.0, 1.1 und Trunk) portieren möchten. Wichtig ist, dass Sie für jede Hauptversion der Software, die Sie verwalten, über eine Verzweigung verfügen, die die neueste Version des Codes für diese Version enthält.


Eine andere Verwendung von Verzweigungen ist für Merkmale. Hier verzweigen Sie den Zweig (oder eine Ihrer Zweigstellen) und arbeiten isoliert an einer neuen Funktion. Sobald die Funktion abgeschlossen ist, fügen Sie sie wieder zusammen und entfernen die Verzweigung.

  • Stamm / - Entwicklungsversion, soll bald 1.2 sein
  • Zweigniederlassungen / 1.1 - kommende Version 1.1.0
  • Zweige / UI-Rewrite - experimenteller Feature-Zweig

Die Idee davon ist, wenn man an etwas Störendem arbeitet (das andere Leute davon abhalten würde, ihre Arbeit zu machen), etwas Experimentelles (das vielleicht nicht einmal eingeht) oder möglicherweise nur etwas, das eine lange Zeit in Anspruch nimmt (und Sie haben Angst, wenn es eine 1.2-Version halten, wenn Sie bereit sind, 1.2 aus dem Stamm zu verzweigen), können Sie es isoliert in Zweig tun. Im Allgemeinen halten Sie es mit dem Trunk auf dem neuesten Stand, indem Sie die Änderungen ständig integrieren, wodurch es einfacher wird, sich wieder zu integrieren (wieder mit dem Trunk zu verbinden), wenn Sie fertig sind.


Beachten Sie auch, dass das Versionierungsschema, das ich hier verwendet habe, nur eines von vielen ist. Einige Teams würden Bug Fix / Maintenance Releases wie 1.1, 1.2, etc., und große Änderungen wie 1.x, 2.x, etc. machen. Die Verwendung hier ist die gleiche, aber Sie können den Zweig "1" oder "1 .x "statt" 1.0 "oder" 1.0.x ". (Beiseite, Semantische Versionierung ist eine gute Anleitung zum Ausführen von Versionsnummern).


536
2017-09-20 19:00



Zusätzlich zu dem, was Nick gesagt hat, könnt ihr mehr darüber erfahren Gestreamte Linien: Verzweigungsmuster für parallele Softwareentwicklung

enter image description here

In dieser Figur main ist der Stamm, rel1-maint ist ein Zweig und 1.0 ist ein Tag.


92
2017-08-19 13:58



Im Algemeinen (Tool Agnostic View), ist eine Verzweigung der Mechanismus für die parallele Entwicklung. Ein SCM kann 0 bis n Zweige haben. Subversion hat 0.

  • Kofferraum ist ein Hauptzweig empfohlen von Subversion, aber Sie sind in keiner Weise gezwungen, es zu schaffen. Man könnte es "Main" oder "Releases" nennen, oder gar keines!

  • Ast repräsentiert eine Entwicklungsleistung. Es sollte niemals nach einer Ressource (wie 'vonc_branch') benannt werden, sondern nach:

    • ein Zweck 'myProject_dev' oder 'myProject_Merge'
    • ein Freigabeumfang 'myProjetc1.0_dev'oder myProject2.3_Merge' oder 'myProject6..2_Patch1' ...
  • Etikett ist ein Schnappschuss von Dateien, um leicht zu diesem Zustand zurückzukehren. Das Problem ist, dass Tag und Zweig in Subversion gleich sind. Und ich würde auf jeden Fall den paranoiden Ansatz empfehlen:

    Sie können eines der Skripts für die Zugriffssteuerung verwenden, die mit Subversion bereitgestellt werden, um zu verhindern, dass jemand etwas anderes tut, als neue Kopien im Bereich Tags zu erstellen.

Ein Tag ist endgültig. Sein Inhalt sollte sich niemals ändern. NOCH NIE. Je. Sie haben eine Zeile in der Release Note vergessen? Erstellen Sie ein neues Tag. Veraltet oder entferne das alte.

Jetzt lese ich viel darüber, "das und jenes in solchen und jenen Zweigen zusammenzufliessen, dann endlich im Stammzweig". Das wird .. genannt Arbeitsablauf zusammenführen und da ist hier ist nichts Pflicht. Es ist nicht, weil du einen Stammzweig hast müssen zusammenführen etwas.

Per Konvention kann der Stammzweig den aktuellen Stand Ihrer Entwicklung darstellen, aber das ist für ein einfaches sequenzielles Projekt, das ist ein Projekt, das

  • keine "im Voraus" -Entwicklung (für die Vorbereitung der nächsten Version, die solche Änderungen impliziert, dass sie nicht mit der aktuellen "Stamm" -Entwicklung kompatibel sind)
  • kein massives Refactoring (zum Testen einer neuen technischen Entscheidung)
  • keine langfristige Wartung einer früheren Version

Denn mit einem (oder allen) dieser Szenarios erhalten Sie vier "Trunks", vier "aktuelle Entwicklungen", und nicht alles, was Sie in dieser parallelen Entwicklung tun, muss notwendigerweise wieder in "Trunk" zusammengeführt werden.


73
2017-08-19 13:25



In SVN sind ein Tag und ein Zweig sehr ähnlich.

Etikett = eine definierte Zeitscheibe, die normalerweise für Releases verwendet wird

Ast = auch ein definiertes Zeitfenster, in dem die Entwicklung fortgesetzt werden kann, normalerweise für Hauptversionen wie 1.0, 1.5, 2.0 usw. verwendet. Wenn Sie die Veröffentlichung freigeben, markieren Sie die Verzweigung. Auf diese Weise können Sie weiterhin eine Produktionsversion unterstützen und gleichzeitig Änderungen im Stamm vornehmen

Kofferraum= Entwicklungsarbeitsraum, hier sollte die gesamte Entwicklung stattfinden und dann werden die Änderungen von den Zweigfreigaben wieder zusammengeführt.


36
2017-08-19 13:27



Sie haben eigentlich keine formale Bedeutung. Ein Ordner ist ein Ordner zu SVN. Sie sind eine allgemein akzeptierte Möglichkeit, Ihr Projekt zu organisieren.

  • Im Kofferraum behalten Sie Ihre Hauptentwicklungslinie. Der Branch-Ordner ist der Ort, an dem Sie möglicherweise Zweige erstellen, die in einem kurzen Post schwer zu erklären sind.

  • Eine Verzweigung ist eine Kopie einer Teilmenge Ihres Projekts, an der Sie getrennt vom Stamm arbeiten. Vielleicht ist es für Experimente, die nirgendwohin gehen, oder vielleicht ist es für die nächste Version, die Sie später wieder in den Stamm zusammenführen werden, wenn es stabil wird.

  • Und der Tag-Ordner dient zum Erstellen von getaggten Kopien Ihres Repositories, normalerweise an Release-Checkpoints.

Aber wie ich schon sagte, zu SVN ist ein Ordner ein Ordner. branch, trunk und tag sind nur eine Konvention.

Ich benutze das Wort "kopiere" großzügig. SVN erstellt keine vollständigen Kopien der Objekte im Repository.


28
2017-08-19 13:37



Das Kofferraum ist die Entwicklungslinie, die den neuesten Quellcode und die neuesten Funktionen enthält. Es sollte die neuesten Fehlerkorrekturen enthalten sowie die neuesten Funktionen, die dem Projekt hinzugefügt wurden.

Das Geäst werden normalerweise verwendet, um etwas außerhalb des Rumpfes (oder einer anderen Entwicklungslinie) zu tun, das sonst passieren würde Unterbrechung der Bau. Neue Features werden oft in einem Zweig erstellt und dann wieder in den Stamm eingebunden. Branchen enthalten oft Code, der für die Entwicklungslinie, von der er sich abzweigt, nicht unbedingt genehmigt ist. Zum Beispiel könnte ein Programmierer eine Optimierung für etwas in einer Verzweigung versuchen und erst dann wieder in die Entwicklungslinie einfließen, wenn die Optimierung zufriedenstellend ist.

Das Stichworte sind Momentaufnahmen des Repositorys zu einer bestimmten Zeit. Auf diesen sollte keine Entwicklung stattfinden. Sie werden am häufigsten verwendet, um eine Kopie von dem zu erhalten, was an einen Client freigegeben wurde, damit Sie leicht auf das zugreifen können, was ein Client verwendet.

Hier ist ein Link zu einem sehr guten Leitfaden zu Repositories:

Die Artikel in Wikipedia sind ebenfalls lesenswert.


12
2018-06-30 11:50