Ich frage mich, ob es noch andere Faktoren gibt, die man für die Standardpraxis der Verwendung von Subversion in Betracht ziehen sollte.
Die wenigen, die ich habe, sind:
Verzeichnisstruktur von / tags / trunk und / branches
Alle Arbeiten werden in einem Trunk ausgeführt, der die Funktionalität nicht unterbricht
Verzweigen Sie, wenn größere strukturelle Änderungen vorgenommen werden oder wenn ein Feature hinzugefügt wird, das die Kernfunktionalität (je nach Präferenz) unterbricht.
Tags enthält stabile Versionen
Führen Sie immer ein Update durch, bevor Sie mit der Arbeit beginnen
Übernimmt Änderungen am Ende des Tages / wenn eine Funktion hinzugefügt wurde
Commit-Notizen enthalten eine relevante Beschreibung
Basierend auf Feature committieren - nicht committieren
Ich stehe in Konflikt mit der Regel, die am Ende des Tages und wenn ein Feature hinzugefügt wurde. Ich sage am Ende des Tages, um sicherzustellen, dass das Repository so aktuell wie möglich ist. Der Code am Ende des Tages kann jedoch unvollständig sein oder die Funktionalität unterbrechen. Wenn Sie jedoch nur bei der Ausführung von Features festschreiben, kann dies zu veralteten / konfliktbedingten Konflikten führen.
Ich würde mich freuen über Ihre Kritik an meinen Ideen und Ideen, die ich verpasst habe.
Danke!
Einige weitere Anmerkungen: (habe versucht, das, was bereits gesagt wurde, nicht zu wiederholen.)
Zweige:
Abgesehen von der Verzweigung für die oben erwähnten großen Teile der Feature-Entwicklung können Sie verzweigen, wenn Sie an Post-Release-Fixes arbeiten müssen, während parallele Arbeiten auf der Hauptlinie / dem Stamm weiterlaufen.
Reverse merge regelmäßig, wenn Sie Zweige verwenden, die lange leben, ohne mit der Mainline-Entwicklung zusammengeführt zu werden. Dies wird dazu beitragen, mit der Stammentwicklung synchron zu bleiben und die Komplikationen eines Big Bang Merge zu minimieren.
Achten Sie darauf, wie Sie Ihre Filialen benennen. Wir versuchen, die Zweige nach dem Meilenstein zu benennen, auf dem sie basiert. Es hilft, wenn Sie schnelle Diffs oder Berichte benötigen, oder sogar wenn Sie nach etwas suchen, wenn die Namen selbsterklärend sind.
Da die Verzweigung in SVN eine billige Kopie ist, versuchen wir immer, im Stamm des Projektverzeichnisses zu verzweigen (wenn es der Ordnerstamm selbst ist, dann wird der Zweig aus dem Stamm entfernt) - dies vermeidet später Verwirrung darüber, wer wo abgezweigt hat und keine Befehle ausführen muss, um es herauszufinden. Und wenn Sie Sachen von einer Verzweigung auschecken müssen, steht Ihnen alles unter der Verzweigung zur Verfügung --- wenn Sie sie brauchen.
Befehle:
Ich stimme häufig und in logischen Blöcken für Commits, so dass Sie die zugehörigen Dateien mit einer gemeinsamen Commit-Nachricht verknüpfen können. Dies ist ideal, wenn Sie ein Protokoll erstellen möchten, und das Reporting erfolgt in Chunks mit dem Bündel von Dateien, die alle mit relevanten Kommentaren verknüpft sind.
Ich stimme für häufige Commits, wenn nicht jeden Tag. Es ist eine Einstellung. Sobald Sie die Vorteile eines frühen Commits sehen (natürlich nachdem die Entwickler nach grundlegenden Kompilierungsfehlern gesucht haben und Komponententests in ihrer Entwicklungsumgebung ausgeführt haben), würden Sie sich über diese frühen Fehler / Build-Probleme freuen. Wenn Sie planen, nächtliche Builds auszuführen oder ein kontinuierliches Integrationstool zu verwenden, sollten Sie die Leute so früh wie möglich dazu bringen, sich zu verpflichten, einen Einblick in die integrierten Arbeitsabläufe zu erhalten und Tests darauf durchzuführen. p>
Tags:
Du solltest immer ein Update vor dem Commit machen, um mögliche Konflikte mit anderen Commits anderer Leute und schmerzhaften Zusammenführungen zu vermeiden.
Außerdem sollte jedes Commit etwas Bedeutungsvolles enthalten, wie einen Bugfix oder ein neues Feature, oder eine Verbesserung zu einem bestehenden, etwas, das in der Log-Nachricht sinnvoll sein kann. Ein Quellcodeverwaltungstool ist kein Backup-Tool, daher sollte ein "End-of-the-Day" Commit ohne sinnvollen Inhalt vermieden werden.
Wenn ein "Feature" mehr als ein paar (4-6) Stunden dauern würde, würde ich entweder
"Wenn Sie jedoch nur bei der Ausführung von Features ein Commit ausführen, kann dies zu veralteten / Konflikten führen?"
Wenn die Änderung so groß ist, dass Sie sich darüber Sorgen machen, sollten Sie wahrscheinlich verzweigt haben. Dies würde es Ihnen ermöglichen, kleinere Commits zu machen, wenn Sie inkrementell arbeiten, ohne den Build zu unterbrechen, und nach dem Zusammenführen in trunk einen eindeutigen Verlauf hinterlassen.
Ich würde versuchen, so oft wie möglich zu begehen. Um dies zu ermöglichen, müssen Sie sicherstellen, dass der Code, den Sie schreiben, noch nicht verwendet wird oder dass alle Tests bestanden werden. Wenn Sie in einem dieser beiden Modi bleiben (wobei letzterer viel besser ist als der erstgenannte), sollten Sie sich keine Gedanken über diese großen Zeiträume machen müssen, in denen Sie sich nicht festlegen können.
TDD hilft in dieser Hinsicht sehr.
Zweige sind eine gute Idee, um große, möglicherweise brechende Änderungen vorzunehmen. Wenn Trunk gleichzeitig aktualisiert wird, können Sie Trunk gelegentlich mit Branch verbinden, um den Zweig auf dem neuesten Stand zu halten.
Übergeben Sie eine atomare Menge verwandter Änderungen. Machen Sie keinen großen Commit mit unzusammenhängenden Änderungen am ganzen Körper. Dies erleichtert die Verfolgung spezifischer Änderungen.
Sie können mehrere Checkouts derselben Quelle haben - nützlich, wenn Sie mit nicht verwandten Änderungen experimentieren.
Vermeiden Sie die Übertragung von fehlerhaftem Code oder Code mit fehlgeschlagenen Tests oder anderen offenen Problemen.
Es gibt viele Variationen in Bezug auf die Quellcode-Steuer-Workflows. Die eine, die wir verwenden, ist die Erweiterung dessen, was Sie in Ihrem Beitrag beschreiben. Ihr Workflow ist gut genug für geringfügige Änderungen, aber nicht, wenn mehrere Teams an verschiedenen Problemen von erheblicher Komplexität arbeiten.
Was wir machen, ist für jedes Team eine Verzweigung, dann kann sich das Team für die Team- (Projekt-) Filiale verpflichten. Jedes Team ist auch dafür verantwortlich, den Teamzweig mit dem Stamm zu synchronisieren, indem Stamm zu Zweig zusammengeführt wird, vorzugsweise nach jedem Festschreiben an den Stamm. Nachdem das Projekt abgeschlossen ist, wird die Verzweigung wieder in den Stamm eingefügt (neu integriert) und gelöscht.
Dieser Ansatzzweig - Zusammenführen ... Zusammenführen - Zusammenführen zurück - Löschen funktioniert gut für uns
Ich war kürzlich an der Verbesserung der Software Configuration Management (SCM) -Techniken beteiligt, die bei dem Unternehmen, für das ich arbeite, im Einsatz sind. Wir fanden heraus, dass sowohl "Verzweigung für Entwicklung" als auch "Verzweigung für Freisetzung" ziemlich gut funktionieren.
Ein gutes Buch über SCM-Muster / Standardverfahren, das ich hilfreich fand, ist "Software Configuration Management Patterns: Effektive Teamarbeit, praktische Integration von Berczuk und Appleton".
Tags und Links svn