SVN Best Practices - Arbeiten in einem Team

Ich fange mit SVN an. Ich kenne die Grundbefehle und verstehe die Grundprinzipien. Ich habe mich gefragt, ob jemand Tipps oder Best Practices für die Arbeit mit Subversion in einer Teamumgebung hat.

Ich kann den Vorteil des Hinzufügens einigermaßen ausführlicher Nachrichten beim Festschreiben von Code erkennen, aber gibt es andere Dinge, die ich berücksichtigen sollte?

Vielen Dank für all die tollen Antworten - sie haben sehr geholfen.

Ermutigen Sie zu häufigen Commits. Teamkollegen, die neu in der Versionskontrolle sind, haben möglicherweise das Gefühl, dass sie den Code aus dem Repository heraushalten müssen, bis "es richtig funktioniert". Bringen Sie allen bei, sich früh und häufig zu engagieren, um Probleme so schnell wie möglich zu finden. Anstatt den Code zu halten, bis er funktioniert, schlagen Sie vor, dass Ihre Teamkollegen Zweige für Funktionen erstellen, die den Stamm beschädigen könnten. Das führt zu...

Richten Sie eine Verzweigungs- und Markierungspraxis ein. Ermutigen Sie Ihre Teamkollegen, zusätzlich zu Zweigen für Funktionen Zweige für Fehlerbehebungen zu verwenden. Kennzeichnen Sie wichtige Fehlerbehebungen zu Beginn und am Ende der Arbeit. Pflegen Sie Tags (und möglicherweise Zweige) für Produktions- / Qa-Releases.

Richten Sie eine Richtlinie für Trunk ein und halten Sie sich daran. Ein Beispiel könnte sein: "Trunk muss immer fehlerfrei erstellt werden." oder "Kofferraum muss immer alle Unit-Tests bestehen". Alle Arbeiten, die die Standards von Trunk noch nicht erfüllen können, müssen in einer Zweigstelle ausgeführt werden.

Übernehmen Sie keine Formatierungsänderungen mit Codeänderungen

Wenn Sie das Leerzeichen einer riesigen Datei ( Control+ K+ D) umstrukturieren möchten , ist dies in Ordnung. Übernehmen Sie die Formatierungsänderung getrennt von der tatsächlichen logischen Änderung. Gleiches gilt, wenn Sie Funktionen in Dateien verschieben möchten. Übernehmen Sie das Verschieben getrennt von der eigentlichen Bearbeitung.

Eines der Schlüsselkonzepte, an dem ich immer festhalte, ist das gemeinsame Festschreiben verwandter Codeänderungen . Die Konsequenz ist, keine nicht verwandten Codeänderungen in demselben Commit festzuschreiben . Dies bedeutet, dass Sie nicht zwei Fehler in einem Commit beheben (es sei denn, es handelt sich um denselben Fix), und dass Sie nicht in jedem der beiden Commits einen halben Fehler beheben. Wenn ich einem nicht verwandten Teil des Systems, den ich dann für eine andere Arbeit benötige, eine neue Erweiterung oder etwas hinzufügen muss, lege ich die Erweiterung separat (und zuerst) fest. Die Idee ist, dass jede Änderung, die jemand möglicherweise selbst vornehmen möchte (oder die er selbst zurücksetzen möchte), ein separates Commit sein sollte. Es erspart Ihnen jede Menge Kopfschmerzen, wenn es darum geht, Zusammenführungen durchzuführen oder defekte Funktionen zurückzusetzen.

Es wurde bereits viel erwähnt, und hier sind noch einige mehr:

1. Wenn Sie Dateien haben, die Sie nicht in der Quellcodeverwaltung haben möchten (z. B. Konfiguration, kompilierte Dateien usw.), fügen Sie sie der Ignorierliste hinzu . Auf diese Weise bemerken Sie alle Dateien, die Sie vergessen haben, hinzuzufügen, indem Sie immer eine leere Liste von Dateien erwarten, die SVN als unbekannt angezeigt werden.

2. Fügen Sie ein Post-Commit-Ereignis hinzu, das eine E-Mail an Ihre Entwickler-Mailingliste (oder eine für dieses Ziel spezifische) sendet, die sich auf die festgeschriebene Änderung und im Idealfall auf den Patch dafür bezieht.

3. Integrieren Sie sich in Ihren Bug-Tracker, sodass Verweise auf Commits in den Bugs / Feature-Anforderungen mit Links zu den Diffs angezeigt werden. Bug-Tracker wie MantisBT unterstützen dies.

4. Erwägen Sie die Integration mit kontinuierlicher Integration (z. B. CruiseControl.NET ), NAnt for Build und NUnit / VS für Komponententests . Auf diese Weise werden nach dem Einchecken eines Benutzers oder in einem festgelegten Intervall der Code kompiliert, Komponententests ausgeführt und der Entwickler erhält eine Rückmeldung über den Prozess. Dies würde auch den Rest des Teams alarmieren, wenn das Repository defekt ist (dh nicht erstellt wird).

Nun, die Grundlagen:

• Erstellen Sie Tags, bevor Sie die Qualitätssicherung für eine Version starten
• Erstellen Sie Tags vor riskanten Änderungen (dh großen Refaktoren).
• Erstellen Sie Zweige für freigegebene Versionen, um den Code einzufrieren.
• Stellen Sie sicher, dass die Benutzer wissen, dass sie aktualisiert werden müssen, bevor Sie mit der Arbeit an einem Code beginnen, und aktualisieren Sie ihn erneut, bevor Sie ihn festschreiben.
• SVN ermöglicht das mehrfache Auschecken derselben Datei durch verschiedene Benutzer. Stellen Sie sicher, dass jeder auftretende Konflikt gelöst wird.
• Verwenden Sie niemals dasselbe SVN-Konto für mehr als einen Benutzer. Es können schreckliche Dinge entstehen.

Die Antworten, die die Leute geben, sind großartig. Vieles davon ist im svn-Benutzerdokument für Best Practices für SVN zusammengefasst .
Wiederholen:

1. Richten Sie Ihre Repository-Struktur ein (Sie sollten ein Projektstammverzeichnis mit Trunk, Zweigen und Tags darunter haben).
2. Wählen Sie Ihre Richtlinie für die Verzweigung (private Zweige, Zweige pro Meilenstein / Release / Bug usw.) und halten Sie sich daran - ich würde mehr Verzweigungen als weniger empfehlen, aber keine privaten Zweige erforderlich
3. Wählen Sie Ihre Richtlinie für das Taggen aus - mehr Tags, desto besser, aber entscheiden Sie sich vor allem für Ihre Tag-Namenskonventionen
4. Wählen Sie Ihre Richtlinie für die erneute Festlegung von Trunk - halten Sie Trunk so "sauber" wie möglich. Sie sollte jederzeit freigegeben werden können

Ich möchte Best Practices zusammenfassen, an die ich mich halte:

1. Legen Sie keine Binärdateien fest . Es sollte ein separates Repository für Binärdateien wie Nexus , Ivy oder Artifactory geben .

2. Es sollte eine Repository-Struktur geben . Persönlich verwende ich folgende Repository-Struktur:

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. Verwenden Sie eine bestimmte Liste von Verzweigungstypen . Meine Liste lautet wie folgt: Experimentell , Wartung , Versionen , Plattformen , Releases .
4. Verwenden Sie bestimmte Arten von Tags : PA(Pre-Alpha), A(Alpha), B(Beta), AR(Alpha-Release), BR(Beta-Release), RC(Release-Kandidat), ST(Stable).
5. Minimieren Notwendigkeit des Zusammenführens . Es sollte Regeln geben, wann das Zusammenführen möglich / gefördert wird und wann nicht.
6. Versionsnummerierung . Es sollte einen etablierten Ansatz zur Versionsnummerierung geben, an den man sich halten kann. Normalerweise wird es in einem Dokument wie Software Configuration Management Plan beschrieben und ist Teil einer allgemeinen Projektdokumentation. Persönlich verwende ich einen komplexen Versionsnummerierungsansatz. Nach diesem Ansatz weisen Versionen folgende Muster auf: Nxx (Wartungs- / Supportzweige), NMx (Release-Zweig), NxK (Build), NMK (Release).
7. Verpflichte dich so oft wie möglich . Wenn dies schwierig ist (z. B. wenn zu viele Änderungen vorgenommen werden müssen, um Funktionen zu implementieren und sogar Code zu kompilieren), sollten experimentelle Verzweigungen verwendet werden.
8. Kofferraum sollte die neueste Entwicklung enthalten . Wenn beispielsweise die Wahl besteht, wo eine neue Hauptversion ( Nxx ) der Anwendung im Trunk oder in der Verzweigung entwickelt werden soll, sollte immer die Entscheidung zugunsten des Trunk getroffen werden . Die alte Version sollte in den Wartungs- / Support- Zweig verzweigt werden. Es wird davon ausgegangen, dass es eine klare Unterscheidung zwischen Hauptversionen gibt und deren Besonderheiten (Architektur, Kompatibilität) so früh wie möglich auftreten .
9. Strenge Richtlinie zum Freigeben von Builds für Release-Zweige . In der Zwischenzeit sollte es für Trunk nicht unbedingt streng sein, solange es entweder eine experimentelle Entwicklung oder eine Codebasis hat, für die Zusammenführungsprobleme gelöst werden müssen.
10. Verwenden Sie svn: externals . Es ermöglicht Ihnen, Ihr Projekt zu modularisieren, ein transparentes Release-Management-Verfahren einzurichten, verschiedene Funktionen zu teilen und zu erobern.
11. Verwenden Sie die Problemverfolgung . Sie können auf die Problemreferenz in der Festschreibungsnachricht hinweisen.
12. Deaktivieren Sie leere Festschreibungsnachrichten . Dies kann mithilfe von Pre-Commit-Hooks erfolgen.
13. Definieren Sie, welche Zweige Sie kontinuierlich integrieren möchten . Zum Beispiel bevorzuge ich die kontinuierliche Integration für Trunk- , Wartungs- und Release- Zweige.
14. Richten Sie eine kontinuierliche Integrationsrichtlinie für verschiedene Arten von Zweigen ein. Wie ich bereits erwähnt habe, gelten für Release- Zweige die strengsten Regeln zum "Nicht brechen des Builds" , während Trunk- und Wartungszweige manchmal beschädigt werden können. Es gibt auch einen Unterschied zwischen der Liste der Inspektionen, die an den Zweigen Kofferraum / Wartung und Freigabe durchgeführt werden .

Sie finden einen Überblick über meine Best Practices für Subversion in Form eines Diagramms, in dem die wichtigsten Prinzipien des von mir verwendeten Ansatzes für das Softwarekonfigurationsmanagement dargestellt sind.

Eine Sache, die ich als sehr nützlich empfunden habe, ist die Eigenschaft svn: external, dh Sie können Verzeichnisse aus anderen Repositorys in Ihre eigenen verweisen. Es gibt wirklich schöne Möglichkeiten, Ihren Code und Ihre Daten zu organisieren. Einige Beispiele sind:

1. Wenn Sie separate Repositorys für Code haben, können Sie verschiedene Module / Bibliotheken und Referenzen in den von Ihnen verwendeten verwenden. Dies bedeutet, dass Sie für jede ausführbare Datei ein Meta-Repository haben können. Wenn es sich um eine kleine ausführbare Datei handelt, die nur wenige Module verwendet, müssen Sie nicht den gesamten Baum auschecken. Dies hat zur Folge, dass Sie SVN-Revisionsnummern pro Modul erhalten.
2. Das Hinzufügen großer Binärdaten wie kompilierter Versionen von Bibliotheken zum Code-Repository wird im Allgemeinen als schlechte Angewohnheit angesehen, kann jedoch sehr praktisch sein. Wenn Sie nur alle Versionen aller von Ihnen verwendeten Bibliotheken zu einem anderen Repository hinzufügen, können Sie das Beste aus zwei Welten herausholen. Sie verweisen in den Versionen der Bibliotheken, die Sie verwenden, auf Ihr Code-Repository. Beim Auschecken Ihres Code-Repositorys erhalten Sie sowohl den Code als auch die Binärdateien. Die Binärdateien werden jedoch in einem großen Repository gespeichert, das Sie nicht so streng sichern müssen wie Ihr Quellcode, und das Quellcode-Repository bleibt klein und enthält nur Text.

Verwenden Sie die Integration in Ihre Bug-Tracking-Software. Wenn Sie Bugzilla verwenden , können Sie es so einrichten, dass Ihr SVN-Kommentar automatisch als Kommentar zum angegebenen Fehler hinzugefügt wird, wenn Ihr Kommentar mit "Bug XXXX" beginnt, einschließlich eines Links zu Ihrer SVN-Weboberfläche zu dieser Revision.

Erfahren Sie mehr über die Tools und Konventionen für das Verzweigen und Zusammenführen von SVN.

Der beste Weg, mit anderen Teammitgliedern zusammenzuarbeiten, besteht darin, die Arbeit in vollständige Entwicklungsfunktionen / -korrekturen aufzuteilen und dann an einzelnen Änderungen in einer Zweigstelle zu arbeiten. Führen Sie dann die Änderungen wieder in den Hauptzweig / die Hauptleitung ein, wenn Sie fertig / bereit / für die Zusammenführung genehmigt sind.

Auf diese Weise können Einzelpersonen auf ein gemeinsames Ziel hinarbeiten (entweder auf demselben Zweig oder auf getrennten Zweigen), ohne mit anderen Änderungen zusammenzustoßen.

Ihr Kilometerstand kann variieren, und dies kann für nur zwei oder mehr Personen übertrieben sein.

Es macht es viel einfacher, wenn Sie gute Tools verwenden, die sich gut in SVN integrieren lassen. Diese machen es einfach zu sehen, was geändert wurde, und dann alle oder einen Teil Ihrer Änderungen festzuschreiben und Ihre Arbeitskopie regelmäßig auf die neueste Version in SVN zu aktualisieren.

Ich empfehle Tortoise SVN (wenn Sie Windows verwenden) und Visual SVN (wenn Sie VS verwenden).

Überprüfen Sie auch, ob Sie es so einrichten können, dass Sie bei jeder Festschreibung eine E-Mail oder eine ähnliche Benachrichtigung erhalten (normalerweise auch mit der Festschreibungsnachricht und einer Liste der geänderten Dateien). Dienstleistungen wie CVSDude bieten dies an. Ich finde es hilfreich zu wissen, dass ein Update durchgeführt wurde, und dann eine Vorstellung davon zu haben, was in diesem Update enthalten ist, bevor ich meine Arbeitskopie aktualisiere.

Neben Verzweigungsrichtlinien et al. (wo eine Größe definitiv nicht für alle passt), sollten Sie gute Commits haben:

• Das Commit sollte sich nach Möglichkeit auf eine einzelne Arbeit beziehen . Eine Fehlerbehebung, eine neue Funktion - es sollte eine gewisse Logik für die von Ihnen vorgenommenen Änderungen geben
• Das Commit sollte einen beschreibenden Kommentar enthalten, der Ihnen beim Durchsuchen des Repository-Verlaufs hilft. Die meisten Leute schlagen vor, am Anfang einen einzigen Satz zu schreiben, der das gesamte Commit beschreibt, und einen detaillierteren Bericht unten
• Wenn möglich, sollten Sie das Commit nach Möglichkeit an Ihr Bug-Tracking-System binden. Trac, Redmine et al. Sie können Links von Fehlern zu Commits und umgekehrt erstellen, was sehr praktisch ist.

Die goldene Regel für die Quellcodeverwaltung: Früh einchecken, häufig einchecken

Tipps zum Organisieren Ihres Repositorys:

• Wie organisieren Sie Ihr Versionskontroll-Repository?
• SVN-Buch Kapitel 5. Repository-Verwaltung
• Repository-Layout

Wenden Sie sich an Ihr Team, um Änderungen zu erfahren, oder schauen Sie sich den Unterschied zumindest sehr genau an, bevor Sie Zusammenführungskonflikte beheben. Bitten Sie sie, den zusammengeführten Code selbst zu überprüfen, um sicherzustellen, dass ihre Ergänzungen bei der Zusammenführung nicht verloren gegangen sind.

Eine Sache, die ich gesehen habe, die fehlerhafte Commits reduziert, ist, gute Pre-Commit-Skripte zu haben. Sie können beispielsweise beliebige Komponententests ausführen, bevor die Änderung festgeschrieben wird. Dies führt dazu, dass die Festschreibungen etwas langsam sind. Sie sparen jedoch Zeit, indem Sie vermeiden, jemandem auf die Zehen zu treten und sich entschuldigen zu müssen. Natürlich wird dies viel schwieriger zu handhaben, wenn Sie ein großes Entwicklungsteam und sehr häufige Commits haben.

Eines der Beispiele für die Integration in die Durchsetzung von Bug-Trackern und Commit-Richtlinien könnten Tracs SVN-Hook-Skripte vor / nach dem Commit sein, die das Commit ablehnen können, wenn die Commit-Nachricht kein Ticket im Bug-Tracker referenziert und Kommentare zu vorhandenen hinzufügt Tickets basierend auf dem Nachrichteninhalt (dh Commit-Nachrichten können so etwas wie "Fixes # 1, # 2 und # 8" enthalten, wobei # 1, # 2, # 8 die Ticketnummern sind).

Best Practice für die Verwendung von SVN :

1. Wenn Sie zum ersten Mal ins Büro gekommen sind und Ihr Eclipse- Projekt geöffnet haben, müssen Sie zunächst Ihr Projekt aktualisieren.

2. Beginnen Sie nach dem Update mit Ihrer Arbeit. Wenn Sie Ihre Codierung abgeschlossen haben, überprüfen Sie ordnungsgemäß, ob Ihre Anwendung ausnahmslos ordnungsgemäß ausgeführt wird. Sobald Sie sicher sind, dass Ihr Code ordnungsgemäß funktioniert, müssen Sie den Code festschreiben.

Hinweis: Während Sie den Code festschreiben, legen Sie ihn nicht direkt fest. Führen Sie eine Synchronisierung mit dem Server durch und überprüfen Sie, welche Daten festgeschrieben werden müssen. Hinweis: Übertragen Sie nicht den gesamten Ordner einmal. Möglicherweise haben Sie einige Änderungen an der Datei für Ihre Anforderung vorgenommen oder einige Dateien in Ihrem lokalen System gelöscht. Die Einstellungen auf dem Server sind jedoch unterschiedlich. Überprüfen Sie also die Dateien einzeln und schreiben Sie den Code fest.

3. Festschreiben / Aktualisieren von Konfliktdateien nicht direkt.

4. Wann überschreiben und aktualisieren?

   Wenn Sie ziemlich sicher sind, dass Sie keine Ihrer lokalen Änderungen benötigen und die Serverkopie vollständig aktualisieren möchten. Beachten Sie, dass Sie beim Überschreiben und Aktualisieren keine Ihrer lokalen Änderungen erhalten.

   Hinweis: Behalten Sie das Projekt nicht länger als einen Tag bei, ohne es zu aktualisieren. Behalten Sie den Code auch nicht für viele Tage bei, ohne sich zu verpflichten.

5. Kommunizieren Sie, wer alle in derselben Komponente arbeiten, und besprechen Sie, welche Änderungen sie täglich vorgenommen haben.

6. Übernehmen Sie die Eigenschaften und die Konfigurationsdatei nur, wenn ein Grund vorliegt. Weil die Einstellungen auf einem Server und in der Cloud unterschiedlich sind.

7. Übertragen Sie keine Zielordner in SVN, sondern nur Quellcode- und Ressourcenordner müssen in einem SVN-Repository verwaltet werden.

8. Wenn Sie Ihren Code verloren haben, geraten Sie nicht in Panik! Sie können die frühere Kopie aus dem SVN-Verlauf zurückerhalten.

9. Checken Sie das Projekt nicht an mehreren Stellen Ihrer Festplatte aus. Kasse es an einem Ort und arbeite damit.

SVN an sich ist ein guter Anfang und einige der anderen Poster haben einige großartige Vorschläge zu Best Practices gemacht.

Das einzige, was ich hinzufügen möchte, ist, dass Sie SVN mit CruiseControl oder TeamCity verbinden sollten, um einen kontinuierlichen Integrationsprozess voranzutreiben. Dadurch werden Build-E-Mails gesendet und alle wissen, wenn jemand den Build abgebrochen hat.

Es wird sehr früh sagen, wer Ihren Prozess verfolgt und wer nicht. Könnte zu Reibereien führen, aber Ihr Team wird auf lange Sicht besser dran sein.

• Präziser Kommentar für jedes Commit

• Brechen Sie nicht den (Haupt-) Build!

• Commit, sobald sich eine logische Einheit ändert

• Vermeiden Sie die Verwendung von Subversion als Backup-Tool

• Ein wenig Verzweigung / Verschmelzung wie möglich

.

Weitere Informationen finden Sie in den Best Practices von SVN .

Arbeiten Sie mit DEV an Zweigen

1. Häufige Commits in Ihrer Filiale
2. Diskrete / modulare Commits für Ihre Niederlassung ( siehe hier )
3. Update / Merge-from Trunk häufig. Sie nicht sitzen auf dem Zweig ohne Umbasierung

Community Trunk

1. Sollte immer bauen / arbeiten
2. Ein Problem pro Commit ( siehe hier ) Meistens, damit Sie oder andere die Dinge einzeln zurücksetzen können
3. Nicht conflate Refactoring / Leerzeichen mit logischen Änderungen ändert. Ihre Teamkollegen werden es schwer haben, aus einem Commit herauszuholen, was Sie tatsächlich getan haben

Denken Sie daran, dass es für Sie (oder wahrscheinlich für andere) umso einfacher ist, je inkrementeller, modularer, diskreter und prägnanter Sie Ihre Commits ausführen:

• Änderungen schrittweise zurücksetzen
• Erkennen Sie visuell, was Sie tatsächlich getan haben, ohne Tonnen von Leerzeichen und Änderungen des Variablennamens zu durchsuchen.
• Die Festschreibungsnachrichten bedeuten mehr, wenn das Verhältnis von geleisteter Arbeit zur Nachrichtenlänge geringer ist.

Verwenden Sie dies für die Kommentarvorlage:

[Aufgabe / Geschichte xxx] [Moll / Dur] [Kommentar] [Folgekommentar] [URL zum Fehler]