Share
Wenn wir Subversion oder SVN sagen, versteht jeder Entwickler, der es verwendet, das, worüber wir sprechen werden. SVN sollte das De-facto-Element eines Entwicklungszyklus sein. Wir können SVN nicht nur mit Codedateien verwenden, sondern auch mit allen Arten von Dateien, die am Entwicklungsprozess beteiligt sind (aber es ist auch nicht auf diese Dateien beschränkt)..
In diesem Artikel werden wir betrachten, wie wir SVN effektiv nutzen können, indem wir einige Praktiken befolgen. Es wird dazu beitragen, Ihren Entwicklungsworkflow zu verbessern und den endgültigen Quellcode stabiler zu gestalten. Wenn wir stabil sagen, bedeutet dies, dass es weniger Konflikte gibt als andere Ansätze. Es ist jedoch nahezu unmöglich, es zu 100% konfliktfrei zu machen, da alle Entwickler ihre eigenen Wege haben, ihre Arbeit zu erledigen.
Wir werden die folgenden Punkte in diesem Artikel durchgehen:
Dieser Abschnitt befasst sich mit der Struktur Ihres Repositorys. Dies kann entweder ein einzelnes Repository oder mehrere Repositorys sein. Beide Muster sind in der Industrie weit verbreitet und beide haben ihre eigenen Vor- und Nachteile. Es liegt also ganz bei uns, welches wir basierend auf unseren Anforderungen verwenden sollten.
In diesem Muster sollten wir ein Repository auf dem SVN-Server erstellen und weiterhin mehrere Projekte in demselben Repository hinzufügen. Wenn wir planen, dieses Muster zu verwenden, sollten wir normalerweise ein Repository ohne die Standard-Repository-Struktur erstellen, d. H. Ohne Verzweigungen, Tags oder Trunk-Verzeichnis. Dies ist jedoch nicht zwingend.
Es gibt verschiedene Möglichkeiten, wie die Menschen diesem Muster folgen. Nachfolgend einige davon:
Wurzel - ProjectA - Zweige - Tags - Stamm - ProjectB - Zweige - Tags - Stamm
Root - ClientA - ProjectA - Branches - Tags - Trunk - ProjectB - Branches - Tags - Trunk - ClientB - ProjectB - Branches - Tags - Trunk
Dieses Muster wird verfolgt, wenn eine kleine Gruppe von Leuten an einigen Projekten arbeitet und die Projektgröße klein bis mittel ist. Dies kann auch für Projekte implementiert werden, die miteinander verwandt sind und bestimmten Code verwenden. Dieses Muster hat seine eigenen Vor- und Nachteile, die unten aufgeführt sind:
Dieses Muster eignet sich für große Projekte, die miteinander in Beziehung stehen können oder nicht. Wie bei der vorherigen Methode hat auch diese Methode ihre eigenen Vor- und Nachteile.
Jede Art von Repository kann drei Elemente enthalten (ist aber nicht darauf beschränkt), nämlich Verzweigungen, Tags und der Trunk. Es gibt keine so gut definierte Definition für die Verwendung dieser drei Elemente. Wir können es auf beliebige Weise ausdrücken. Möchten Sie, dass Tags Ihre Hauptentwicklungslinie sind? Kein Problem, machen Sie das einfach. Niemand wird dich verhaften.
Ihre kleinen Richtlinien haben sich jedoch aufgrund der Erfahrung mit SVN entwickelt, und wir haben einige Richtlinien zu jedem Element.
Der Trunk wird für die neueste / aktuelle Entwicklungslinie verwendet.
Ein Zweig sollte verwendet werden, wenn einige wesentliche Änderungen vorliegen, die die Hauptentwicklungslinie (Trunk) unterbrechen können. Um also ohne Auswirkungen auf den Stamm arbeiten zu können, sollten Sie aus dem Stamm einen Zweig erstellen und die erforderlichen Änderungen daran vornehmen. Später, wenn wir mit den Änderungen fertig sind, können wir diesen Zweig mit dem Stamm zusammenführen.
Tags gelten als Momentaufnahme Ihres Codes an einem bestimmten Punkt, z. MileStone1, Milestone2 usw.
Wir können eine endlose Debatte zu diesem Thema führen, da jeder seine eigene Perspektive hat, während er mit Zweigstellen in SVN arbeitet. Jede Politik hat ihre Vor- und Nachteile, die wir im nächsten Abschnitt sehen werden:
In dieser Richtlinie arbeitet jeder Entwickler nur noch am Trunk, und es wird kein Verzweigen und Zusammenführen hier ausgeführt.
Jeder Entwickler legt fest, dass der Stamm zu jeder Zeit instabil sein kann, was ein größeres Problem sein kann.
In dieser Richtlinie können Entwickler an jeder Funktion in einem separaten Zweig und nicht am Stamm selbst arbeiten. Sobald Änderungen vorgenommen wurden, können sie in einem Zweig überprüft und später mit dem Trunk zusammengeführt werden.
In diesem Muster arbeitet der Benutzer weiter am Trunk, um das Verzweigen und Zusammenführen zu reduzieren. Ein Entwickler sollte jedoch bei Bedarf einen Zweig erstellen.
Wie erkennt man diesen Bedarf? In diesem Fall sollte der Entwickler sich die Frage stellen: Was ist, wenn für meine Änderung mehrere Änderungen erforderlich waren? Wenn ich alle auf einmal begehen werde, wird dies ein Problem für die Peer Review darstellen oder schaffen?
Wenn Sie eine der obigen Fragen mit Ja beantworten, sollten Sie einen neuen Zweig für dieses Feature erstellen. Sobald Sie mit dem Feature fertig sind, kann es mit dem Trunk zusammengeführt werden, nachdem der Zweig selbst ordnungsgemäß getestet wurde.
Wir können einen Pre-Commit-Hook verwenden, um sicherzustellen, dass die Entwickler die erforderliche Commit-Nachricht eingegeben haben. Außerdem können wir einen Post-Commit-Hook verwenden, um E-Mails zur Überprüfung des Codes an eine höhere Instanz zu senden.
Es wird immer empfohlen, Ihren Code auf den Kopf zu bringen, um sicherzustellen, dass Sie den neuesten Code bei sich haben. Auf diese Weise werden Konflikte im Code reduziert und die Stabilität verbessert.
Stellen Sie sich vor, Sie haben an mehreren Änderungen gearbeitet und alle Dateien auf einmal festgeschrieben. Sie sagen, Sie haben Aufgabe 1, Aufgabe 2 und Aufgabe 3 abgeschlossen. Könnte ein anderer Entwickler nach einigen Tagen feststellen, welche Dateien zu welcher Aufgabe gehören? Es gibt also eine sehr einfache Regel: Festschreiben Sie jeweils eine Änderung, anstatt mehrere Änderungen in einem einzigen Commit festzuschreiben.
Wir sind Menschen und neigen dazu, Dinge zu vergessen. Daher ist es immer ratsam, eine ausführliche Protokollnachricht zu hinterlegen, während Änderungen an der SVN vorgenommen werden. Dies hilft uns zu verstehen, was zu einem Zeitpunkt festgelegt wurde. Wir können also einfach auf diese Version zurückgreifen, indem wir nur die Protokollnachricht betrachten. Schauen wir uns zwei verschiedene Protokollnachrichten an:
Wenn Sie an einer größeren Aufgabe arbeiten, empfiehlt es sich, häufiger Änderungen vorzunehmen, während Sie an dieser Aufgabe arbeiten, anstatt nach Abschluss der Aufgabe festzuschreiben. Diese Übung hilft Ihnen, in jede Phase dieser speziellen Aufgabe zu gelangen.
Zum Schluss noch ein Hinweis für SVN-Administratoren, immer regelmäßige Sicherungen Ihres Repositorys. Dies hilft Ihnen bei einer Katastrophe.
Wie bereits erwähnt, gibt es keine Regeln für die Verwendung von SVN. Daher habe ich mein Bestes gegeben, um basierend auf meiner allgemeinen Erfahrung einige Richtlinien für die Arbeit mit SVN zu finden.
Accentsconagua