Was bedeuten "Branch", "Tag" und "Trunk" in Subversion-Repositorys?

Ich habe diese Worte viel in Subversion-Diskussionen (und ich denke im allgemeinen Repository) gesehen.
Ich habe SVN in den letzten Jahren für meine Projekte verwendet, aber ich habe nie das vollständige Konzept dieser Verzeichnisse verstanden.

Was meinen sie?

Hmm, ich bin mir nicht sicher, ob ich damit einverstanden bin, dass Nick Re Tag einem Zweig ähnelt. Ein Tag ist nur ein Marker

• Stamm wäre der Hauptteil der Entwicklung, der vom Beginn des Projekts bis in die Gegenwart reicht.

• Bei der Verzweigung handelt es sich um eine Kopie des Codes, der von einem bestimmten Punkt im Trunk abgeleitet wurde und zum Anwenden wichtiger Änderungen am Code verwendet wird, während die Integrität des Codes im Trunk erhalten bleibt. Wenn die wichtigsten Änderungen planmäßig verlaufen, werden sie normalerweise wieder in den Kofferraum integriert.

• Das Tag ist ein Zeitpunkt auf dem Stamm oder einem Zweig, den Sie beibehalten möchten. Die beiden Hauptgründe für die Aufbewahrung wären, dass dies entweder eine Hauptversion der Software ist, ob Alpha, Beta, RC oder RTM, oder dass dies der stabilste Punkt der Software ist, bevor größere Änderungen am Trunk vorgenommen wurden.

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

Die Zweig- und Tag-Teilbäume werden auf folgende Weise vom Stamm unterschieden:

Mit Subversion können Sysadmins Hook-Skripte erstellen , die bei bestimmten Ereignissen zur Ausführung ausgelöst werden. B. eine Änderung am Repository festschreiben. Es ist sehr üblich, dass eine typische Subversion-Repository-Implementierung einen Pfad behandelt, der "/ tag /" enthält und nach der Erstellung schreibgeschützt ist. Das Nettoergebnis ist, dass einmal erstellte Tags unveränderlich sind (zumindest für "normale" Benutzer). Dies erfolgt über die Hook-Skripte, die die Unveränderlichkeit erzwingen, indem sie weitere Änderungen verhindern, wenn das Tag ein übergeordneter Knoten des geänderten Objekts ist.

Subversion hat seit Version 1.5 auch Funktionen hinzugefügt, die sich auf die "Nachverfolgung von Zusammenführungen von Zweigen" beziehen, sodass Änderungen, die für einen Zweig festgeschrieben wurden, mit Unterstützung für inkrementelles "intelligentes" Zusammenführen wieder in den Trunk übernommen werden können.

Erstens, wie @AndrewFinnell und @KenLiu hervorheben, bedeuten die Verzeichnisnamen in SVN selbst nichts - "Trunk, Zweige und Tags" sind einfach eine übliche Konvention, die von den meisten Repositorys verwendet wird. Nicht alle Projekte verwenden alle Verzeichnisse (es ist vernünftigerweise üblich, überhaupt keine "Tags" zu verwenden), und nichts hindert Sie daran, sie so zu nennen, wie Sie möchten, obwohl ein Verstoß gegen die Konvention oft verwirrend ist.

Ich werde das wahrscheinlich häufigste Verwendungsszenario für Zweige und Tags beschreiben und ein Beispielszenario für deren Verwendung geben.

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

• Zweige : Jedes Mal, wenn Sie eine Hauptversion veröffentlichen, wird ein Zweig erstellt. Auf diese Weise können Sie Fehlerbehebungen vornehmen und eine neue Version erstellen, ohne die neuesten - möglicherweise unvollendeten oder nicht getesteten - Funktionen veröffentlichen zu müssen.

• Tags : Jedes Mal, wenn Sie eine Version veröffentlichen (endgültige Version, Release Candidates (RC) und Betas), erstellen Sie ein Tag dafür. Auf diese Weise erhalten Sie eine zeitpunktbezogene Kopie des Codes in diesem Zustand, sodass Sie zurückgehen und bei Bedarf Fehler in einer früheren Version reproduzieren oder eine frühere Version genau so neu veröffentlichen können, wie sie war. Verzweigungen und Tags in SVN sind leichtgewichtig - auf dem Server wird keine vollständige Kopie der Dateien erstellt, sondern nur eine Markierung mit der Aufschrift "Diese Dateien wurden bei dieser Revision kopiert", die nur wenige Bytes belegt. In diesem Sinne sollten Sie sich niemals Gedanken darüber machen, ein Tag für einen freigegebenen Code zu erstellen. Wie ich bereits sagte, werden Tags häufig weggelassen. Stattdessen wird in einem Änderungsprotokoll oder einem anderen Dokument die Versionsnummer bei der Veröffentlichung klargestellt.

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

• Trunk / - Entwicklungsversion, bald 1.0
• Zweige / - leer

Sobald 1.0.0 fertig ist, verzweigen Sie Trunk in einen neuen "1.0" -Zweig und erstellen ein "1.0.0" -Tag. Nun wird weiter daran gearbeitet, was irgendwann 1.1 im Kofferraum sein wird.

• Trunk / - Entwicklungsversion, bald 1.1
• branchs / 1.0 - 1.0.0 Release-Version
• tags / 1.0.0 - 1.0.0 Release-Version

Sie stoßen auf einige Fehler im Code, beheben diese im Trunk und führen die Korrekturen dann in den 1.0-Zweig ein. Sie können auch das Gegenteil tun und die Fehler in der 1.0-Verzweigung beheben und sie dann wieder in den Trunk zusammenführen. In der Regel bleiben Projekte jedoch in einer Richtung zusammengeführt, um die Wahrscheinlichkeit zu verringern, dass etwas fehlt. Manchmal kann ein Fehler nur in 1.0 behoben werden, da er in 1.1 veraltet ist. Es spielt keine Rolle: Sie möchten nur sicherstellen, dass Sie 1.1 nicht mit denselben Fehlern veröffentlichen, die in 1.0 behoben wurden.

• Trunk / - Entwicklungsversion, bald 1.1
• branches / 1.0 - kommende Version 1.0.1
• tags / 1.0.0 - 1.0.0 Release-Version

Sobald Sie genügend Fehler (oder möglicherweise einen kritischen Fehler) gefunden haben, entscheiden Sie sich für eine Version 1.0.1. Sie erstellen also ein Tag "1.0.1" aus dem 1.0-Zweig und geben den Code frei. Zu diesem Zeitpunkt enthält der Trunk 1.1 und der Zweig "1.0" den Code 1.0.1. Wenn Sie das nächste Mal ein Update auf 1.0 veröffentlichen, ist es 1.0.2.

• Trunk / - Entwicklungsversion, bald 1.1
• branches / 1.0 - kommende Version 1.0.2
• tags / 1.0.0 - 1.0.0 Release-Version
• tags / 1.0.1 - 1.0.1 Release-Version

Schließlich sind Sie fast bereit, Version 1.1 zu veröffentlichen, möchten aber zuerst eine Beta durchführen. In diesem Fall führen Sie wahrscheinlich einen "1.1" -Zweig und ein "1.1beta1" -Tag durch. Nun wird die Arbeit an 1.2 (oder vielleicht 2.0) im Trunk fortgesetzt, aber die Arbeit an 1.1 wird im Zweig "1.1" fortgesetzt.

• Trunk / - Entwicklungsversion, bald 1.2
• branches / 1.0 - kommende Version 1.0.2
• branches / 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.1beta1 - 1.1 Beta 1 Release-Version

Sobald Sie 1.1 final veröffentlicht haben, erstellen Sie ein "1.1" -Tag aus dem "1.1" -Zweig.

Sie können 1.0 auch weiterhin beibehalten, wenn Sie möchten, und Fehlerbehebungen zwischen allen drei Zweigen (1.0, 1.1 und Trunk) portieren. Der wichtige Aspekt ist, dass Sie für jede Hauptversion der Software, die Sie warten, einen Zweig haben, der die neueste Codeversion für diese Version enthält.

Eine andere Verwendung von Zweigen ist für Funktionen. Hier verzweigen Sie Trunk (oder einen Ihrer Release-Zweige) und arbeiten isoliert an einer neuen Funktion. Sobald die Funktion abgeschlossen ist, führen Sie sie wieder zusammen und entfernen den Zweig.

• Trunk / - Entwicklungsversion, bald 1.2
• branches / 1.1 - kommende Version 1.1.0
• branches / ui-rewrite - experimenteller Feature-Zweig

Die Idee dabei ist, wenn Sie an etwas Störendem arbeiten (das andere Menschen daran hindern oder behindern würde, ihre Arbeit zu erledigen), etwas Experimentelles (das es möglicherweise nicht einmal schafft) oder möglicherweise nur etwas, das lange dauert (und Sie haben Angst, wenn es eine Version 1.2 aufhält, wenn Sie bereit sind, 1.2 vom Trunk zu verzweigen), können Sie dies isoliert in der Verzweigung tun. Im Allgemeinen halten Sie es mit dem Trunk auf dem neuesten Stand, indem Sie die Änderungen ständig zusammenführen. Dies erleichtert die Wiedereingliederung (Zusammenführen mit dem Trunk), wenn Sie fertig sind.

Beachten Sie auch, dass das hier verwendete Versionsschema nur eines von vielen ist. Einige Teams führen Fehlerbehebungs- / Wartungsversionen als 1.1, 1.2 usw. und größere Änderungen als 1.x, 2.x usw. durch. Die Verwendung hier ist dieselbe, aber Sie können den Zweig "1" oder "1" nennen .x "anstelle von" 1.0 "oder" 1.0.x ". (Abgesehen davon ist die semantische Versionierung eine gute Anleitung zum Erstellen von Versionsnummern).

Zusätzlich zu dem, was Nick gesagt hat, finden Sie weitere Informationen unter Streamed Lines: Verzweigungsmuster für die parallele Softwareentwicklung

In dieser Figur mainist der Stamm, rel1-maintist ein Zweig und 1.0ist ein Tag.

Im Allgemeinen (werkzeugunabhängige Ansicht) ist ein Zweig der Mechanismus, der für die parallele Entwicklung verwendet wird. Ein SCM kann 0 bis n Zweige haben. Subversion hat 0.

• Trunk ist ein von Subversion empfohlener Hauptzweig , aber Sie sind in keiner Weise gezwungen, ihn zu erstellen. Sie könnten es "Haupt" oder "Veröffentlichungen" nennen oder gar keine haben!

• Branch ist ein Entwicklungsaufwand. Es sollte niemals nach einer Ressource (wie 'vonc_branch') benannt werden, sondern nach:

  • ein Zweck 'myProject_dev' oder 'myProject_Merge'
  • ein Release-Perimeter 'myProjetc1.0_dev'or myProject2.3_Merge' oder 'myProject6..2_Patch1' ...

• Tag ist eine Momentaufnahme von Dateien, um problemlos in diesen Zustand zurückzukehren. Das Problem ist, dass Tag und Zweig in Subversion identisch sind . Und ich würde definitiv den paranoiden Ansatz empfehlen:

  Sie können eines der mit Subversion bereitgestellten Zugriffssteuerungsskripte verwenden, um zu verhindern, dass jemand etwas anderes tut, als neue Kopien im Tag-Bereich zu erstellen.

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

Jetzt lese ich viel über "das Zusammenführen von so und so in solchen und solchen Zweigen, dann endlich im Stammzweig". Dies wird als Merge-Workflow bezeichnet, und hier ist nichts obligatorisch . Nicht weil Sie einen Trunk-Zweig haben, müssen Sie etwas zurückführen .

Konventionell kann der Trunk-Zweig den aktuellen Status Ihrer Entwicklung darstellen, dies gilt jedoch für ein einfaches sequentielles Projekt, dh für ein Projekt mit:

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

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

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

Tag = ein definierter Zeitabschnitt, der normalerweise für Releases verwendet wird

Branch = auch eine definierte Zeitspanne, in der die Entwicklung fortgesetzt werden kann. Diese wird normalerweise für Hauptversionen wie 1.0, 1.5, 2.0 usw. verwendet. Wenn Sie dann loslassen, markieren Sie den Branch. Auf diese Weise können Sie weiterhin eine Produktionsversion unterstützen, während Sie Änderungen im Kofferraum vornehmen

Trunk = Entwicklungsarbeitsbereich, hier sollte die gesamte Entwicklung stattfinden, und dann werden Änderungen aus Zweigversionen wieder zusammengeführt.

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

• Im Kofferraum behalten Sie Ihre Hauptentwicklungslinie. Im Zweigordner können Sie Zweige erstellen, die in einem kurzen Beitrag schwer zu erklären sind.

• Ein Zweig ist eine Kopie einer Teilmenge Ihres Projekts, an der Sie getrennt vom Trunk arbeiten. Vielleicht ist es für Experimente, die vielleicht nirgendwo hingehen, oder für die nächste Version, die Sie später wieder in den Kofferraum einbinden, wenn er stabil wird.

• Der Tags-Ordner dient zum Erstellen von getaggten Kopien Ihres Repositorys, normalerweise an Release-Checkpoints.

Aber wie gesagt, für SVN ist ein Ordner ein Ordner. branch, trunkund tag sind nur eine Konvention.

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

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

Die Zweige werden in der Regel aus dem Kofferraum zu tun , etwas weg (oder eine andere Entwicklungslinie) verwendet , die sonst brechen die Build. Neue Funktionen werden häufig in einem Zweig erstellt und dann wieder in den Stamm integriert. Verzweigungen enthalten häufig Code, der nicht unbedingt für die Entwicklungszeile genehmigt ist, von der aus verzweigt wurde. Beispielsweise könnte ein Programmierer eine Optimierung für etwas in einem Zweig versuchen und erst dann wieder in der Entwicklungszeile zusammengeführt werden, wenn die Optimierung zufriedenstellend ist.

Die Tags sind Schnappschüsse des Repositorys zu einem bestimmten Zeitpunkt. Auf diesen sollte keine Entwicklung stattfinden. Sie werden am häufigsten verwendet, um eine Kopie dessen zu erstellen, was für einen Client freigegeben wurde, damit Sie problemlos auf das zugreifen können, was ein Client verwendet.

Hier ist ein Link zu einer sehr guten Anleitung zu Repositories:

• Quellcodeverwaltung HOWTO

Auch die Artikel in Wikipedia sind lesenswert.

Nun, das ist die Sache mit der Softwareentwicklung, es gibt kein konsistentes Wissen über irgendetwas, jeder scheint es auf seine eigene Weise zu haben, aber das liegt daran, dass es sowieso eine relativ junge Disziplin ist.

Hier ist mein ganz einfacher Weg:

Trunk - Das Trunk-Verzeichnis enthält das aktuellste, genehmigte und zusammengeführte Werk. Im Gegensatz zu dem, was viele gestanden haben, ist mein Kofferraum nur für saubere, ordentliche und genehmigte Arbeiten gedacht und kein Entwicklungsbereich, sondern ein Freigabebereich.

Zu einem bestimmten Zeitpunkt, zu dem der Kofferraum zur Freigabe bereit zu sein scheint, wird er markiert und freigegeben.

Zweige - Das Zweigverzeichnis enthält Experimente und laufende Arbeiten. Die Arbeit unter einem Zweig bleibt dort, bis die Zusammenführung in den Kofferraum genehmigt wurde. Für mich ist dies der Bereich, in dem die ganze Arbeit erledigt wird.

Zum Beispiel: Ich kann einen Iterations-5- Zweig für eine fünfte Entwicklungsrunde des Produkts haben, möglicherweise einen Prototyp-9- Zweig für eine neunte Experimentierrunde und so weiter.

Tags - Das Tags-Verzeichnis enthält Snapshots genehmigter Zweige und Trunk-Releases. Immer wenn ein Zweig zum Zusammenführen in den Trunk genehmigt wird oder eine Freigabe des Trunks vorgenommen wird, wird unter Tags eine Momentaufnahme des genehmigten Zweigs oder der Trunk-Freigabe erstellt.

Ich nehme an, mit Tags kann ich leicht durch die Zeit springen, um Punkte zu interessieren.

Ich fand dieses großartige Tutorial zu SVN, als ich die Website des Autors des OpenCV 2-Kochbuchs für die Programmierung von Computer Vision-Anwendungen nachschlug und dachte, ich sollte es teilen.

Er hat ein Tutorial zur Verwendung von SVN und zur Bedeutung der Ausdrücke "Trunk", "Tag" und "Branch".

Zitiert direkt aus seinem Tutorial:

Die aktuelle Version Ihres Softwareprojekts, an der Ihr Team gerade arbeitet, befindet sich normalerweise in einem Verzeichnis namens Trunk . Während sich das Projekt weiterentwickelt, aktualisiert der Entwickler diese Version, behebt Fehler, fügt neue Funktionen hinzu und übermittelt seine Änderungen in diesem Verzeichnis.

Zu jedem Zeitpunkt möchten Sie möglicherweise eine Version einfrieren und einen Schnappschuss der Software erfassen, wie sie sich in dieser Phase der Entwicklung befindet. Dies entspricht im Allgemeinen den offiziellen Versionen Ihrer Software, z. B. denjenigen, die Sie Ihren Kunden liefern. Diese Schnappschüsse befinden sich im Tags- Verzeichnis Ihres Projekts.

Schließlich ist es oft nützlich, irgendwann eine neue Entwicklungslinie für Ihre Software zu erstellen. Dies ist beispielsweise der Fall, wenn Sie eine alternative Implementierung testen möchten, bei der Sie Ihre Software ändern müssen, diese Änderungen jedoch erst dann an das Hauptprojekt senden möchten, wenn Sie entscheiden, ob Sie die neue Lösung übernehmen. Das Hauptteam kann dann weiter an dem Projekt arbeiten, während andere Entwickler am Prototyp arbeiten. Sie würden diese neuen Entwicklungslinien des Projekts in ein Verzeichnis namens branchs stellen .

Das Trunk-Verzeichnis ist das Verzeichnis, mit dem Sie wahrscheinlich am besten vertraut sind, da es die letzten Änderungen enthält. Ihre Hauptcodebasis sollte sich im Trunk befinden.

Das Filialverzeichnis dient zum Speichern Ihrer Filialen, unabhängig davon, um welche es sich handelt.

Das Tags-Verzeichnis dient im Wesentlichen zum Markieren eines bestimmten Satzes von Dateien. Sie tun dies für Dinge wie Releases, bei denen "1.0" diese Dateien bei diesen Revisionen und "1.1" diese Dateien bei diesen Revisionen sein sollen. Normalerweise ändern Sie Tags nicht mehr, sobald sie erstellt wurden. Weitere Informationen zu Tags finden Sie in Kapitel 4. Verzweigen und Zusammenführen (in Versionskontrolle mit Subversion ).

Einer der Gründe, warum jeder eine etwas andere Definition hat, ist, dass Subversion keine Unterstützung für Zweige und Tags implementiert . Subversion sagt im Grunde: Wir haben uns Zweige und Tags mit vollem Funktionsumfang in anderen Systemen angesehen und fanden sie nicht nützlich, also haben wir nichts implementiert. Erstellen Sie stattdessen einfach eine Kopie in ein neues Verzeichnis mit einer Namenskonvention . Dann steht es natürlich jedem frei, etwas andere Konventionen zu haben. Um den Unterschied zwischen einem echten Tag und einer bloßen Kopie + Namenskonvention zu verstehen , lesen Sie den Wikipedia-Eintrag Subversion-Tags und -Zweige .

Tag = ein definierter Zeitabschnitt, der normalerweise für Releases verwendet wird

Ich denke, das ist es, was man normalerweise mit "Tag" meint. Aber in Subversion:

Sie haben eigentlich keine formale Bedeutung. Ein Ordner ist ein Ordner für SVN.

was ich ziemlich verwirrend finde: ein Revisionskontrollsystem, das nichts über Zweige oder Tags weiß. Unter dem Gesichtspunkt der Implementierung denke ich, dass die Subversion-Methode zum Erstellen von "Kopien" sehr clever ist, aber ich muss darüber Bescheid wissen, was ich als undichte Abstraktion bezeichnen würde .

Oder vielleicht benutze ich CVS einfach viel zu lange.

Ich denke, dass ein Teil der Verwirrung auf den Unterschied zwischen dem Konzept eines Tags und der Implementierung in SVN zurückzuführen ist. Für SVN ist ein Tag ein Zweig, der eine Kopie ist. Das Ändern von Tags wird als falsch angesehen. Tools wie TortoiseSVN warnen Sie, wenn Sie versuchen, etwas mit ../tags/ .. im Pfad zu ändern.

Ich bin mir nicht sicher, was "Tag" ist, aber Branch ist ein ziemlich verbreitetes Quellcodeverwaltungskonzept.

Grundsätzlich ist eine Verzweigung eine Möglichkeit, Änderungen am Code zu bearbeiten, ohne die Amtsleitung zu beeinflussen. Angenommen, Sie möchten eine neue Funktion hinzufügen, die ziemlich kompliziert ist. Sie möchten Änderungen einchecken können, während Sie sie vornehmen, möchten jedoch nicht, dass sich dies auf die Amtsleitung auswirkt, bis Sie mit der Funktion fertig sind.

Zuerst würden Sie einen Zweig erstellen. Dies ist im Grunde eine Kopie von Trunk zum Zeitpunkt der Erstellung des Zweigs. Sie würden dann Ihre ganze Arbeit in der Niederlassung erledigen. Alle in der Verzweigung vorgenommenen Änderungen wirken sich nicht auf Trunk aus, sodass Trunk weiterhin verwendet werden kann, sodass andere dort weiterarbeiten können (z. B. Bugfixes oder kleine Verbesserungen). Sobald Ihre Funktion abgeschlossen ist, integrieren Sie den Zweig wieder in den Trunk. Dies würde alle Ihre Änderungen vom Zweig in den Trunk verschieben.

Es gibt eine Reihe von Mustern, die Menschen für Zweige verwenden. Wenn Sie ein Produkt haben, bei dem mehrere Hauptversionen gleichzeitig unterstützt werden, ist normalerweise jede Version ein Zweig. Wo ich arbeite, haben wir eine QS-Niederlassung und eine Produktionsniederlassung. Bevor wir unseren Code für die Qualitätssicherung freigeben, integrieren wir Änderungen in die Qualitätssicherungsniederlassung und stellen sie dann von dort aus bereit. Bei der Freigabe für die Produktion integrieren wir von der QS-Abteilung in die Produktionsabteilung, sodass wir wissen, dass der in der Produktion ausgeführte Code mit dem von der Qualitätssicherung getesteten identisch ist.

Hier ist der Wikipedia-Eintrag zu Zweigen , da sie die Dinge wahrscheinlich besser erklären als ich. :) :)

Kofferraum : Nach jedem Sprint in Agile kommen wir mit einem teilweise versandfähigen Produkt heraus. Diese Releases werden im Kofferraum aufbewahrt.

Zweige : Alle Codes für parallele Entwicklungen für jeden laufenden Sprint werden in Zweigen gespeichert.

Tags : Jedes Mal, wenn wir eine teilweise versandfähige Beta-Version eines Produkts veröffentlichen, erstellen wir ein Tag dafür. Dies gibt uns den Code, der zu diesem Zeitpunkt verfügbar war, und ermöglicht es uns, zu diesem Zeitpunkt zurückzukehren, wenn dies zu einem bestimmten Zeitpunkt während der Entwicklung erforderlich ist.

Für Personen, die mit GIT vertraut sind, entspricht Master in GIT Trunk in SVN.

Zweig und Tag haben in GIT und SVN dieselbe Terminologie.