Richtlinie zur Steuerung des Quellcodes

Das Papier "gestreamte Linien: Verzweigungsmuster für parallele Softwareentwicklung" ist eine hervorragende Diskussion über Verzweigungsmuster wie das Muster "Hauptlinie", das Sie erwähnen - es listet die Optionen in Form von Mustern zusammen mit der Diskussion von Anti-Mustern auf. Einer der Autoren ist Robert Orenstein von Perforce.

Keine leeren Commit-Nachrichten.

Wir verwenden mehrere praktische Regeln als Festschreibungsrichtlinie in unserem Projekt. Diese Regeln helfen uns, jede Revision im Bereitstellungszustand zu halten. Unsere Regeln ähneln denen der KDE-Richtlinie, die hier veröffentlicht wird: Ссылка . Jedes Commit sollte (von höherer zu niedrigerer Priorität) sein:

• Erfolgreich überprüft (kompiliert, getestet, überprüft, FxCop'ed, etc.)
• Atomic (sollte nur eine logische Änderung enthalten, zB Single Bugfix, Refactoring, etc.)
• Nicht redundant (kein unbenutzter Code sollte hinzugefügt werden, comment comment code nicht übernehmen, löschen, nicht versehentlich Formatänderungen vornehmen, etc.)
• Korrekt und vollständig kommentiert
• Übereinstimmende aktuelle Entwicklungsphase (z. B. sollte kein Refactoring in Zweigstellen für Versionsunterstützung erlaubt sein)
• So klein wie möglich, um vorherige Regeln zu erfüllen.

Wir haben ein einfaches Tool namens SvnCommitChecker entwickelt, mit dem wir einige dieser Regeln überprüfen können, bevor wir uns an svn binden. Ich plane, es in naher Zukunft zu Sourceforge mit einem Artikel über Vorteile des Haltens der guten svn Änderungsgeschichte zu setzen.

Ich habe das Buch Practical Perforce sehr gut gebrauchen können. Obwohl Sie möglicherweise nicht mit Perforce arbeiten, denke ich, dass Kapitel 7 (Wie Software entwickelt) und Kapitel 8 (Einfache Codezeilenverwaltung) sehr nützlich sein können. Sie können sie möglicherweise auf Google Bücher überfliegen.

Perforce hat auch viele großartige Artikel zu diesem Thema. Software-Lebenszyklus-Modellierung schreibt über Richtlinien.
Perforce vollständige technische Dokumentation .

Und nein, ich arbeite weder mit Perforce noch mit

Viel Glück, Thomas

Diese beiden sind im Grunde die gleichen:
Versionskontrolle für mehrere agile Teams
Konfigurationsverwaltungs-Verzweigungsstrategie

Wir verwenden diese Strategie, um den Trunk stabil zu machen und es den Entwicklern zu ermöglichen, alles, was sie brauchen, in ihren Zweigen zu tun.

Es gibt ein Problem mit Subversion, da es Cyclic merges aber es kann funktionieren, indem der Entwicklungszweig nach jeder Wiedereingliederung in den Stamm gelöscht wird (irrelevant für andere Versionskontrollsysteme)

Meine Lieblingsrichtlinie lautet "Keine Subversion-Commits, die nicht auf Tickets verweisen + Auto-Trac-Kommentare für jedes Commit": Ссылка

Checken Sie keine Änderungen ein, die einen Build unterbrechen.

Pro-Änderung statt pro Datei festschreiben.

Dies hat folgende Vorteile:

• Sie können später sehen, warum diese einzelne Zeile in dieser exakten Datei geändert wurde (aha, das war Bugfix für Bug # 123). Wenn Sie pro Datei committen, dann beschreiben Commit-Nachrichten in der Regel Änderungen, die in der Datei vorgenommen wurden - was Sie aber trotzdem mit diff sehen können. Wenn Sie sich für eine Änderung verpflichten, erklären Commit-Meldungen in der Regel, warum die Änderung überhaupt vorgenommen wurde.
• Es ist viel einfacher, Änderungen / Bugfixes rückgängig zu machen oder zusammenzuführen.
• Es hilft Ihnen, Ihre Arbeit besser zu organisieren, da Sie sich eindeutig auf einen einzelnen Fehler / eine einzelne Funktion / Änderung konzentrieren, an der Sie gerade arbeiten. Sie begehen, wenn Sie fertig sind.

Manche Leute denken, dass diese Politik mehr Commits produziert, aber aus meiner Erfahrung bekommen Sie doch weniger Commits. Zum Beispiel machen Sie Refactoring, was 50 Dateien betrifft. Nach dem Refactoring haben Sie einen einzelnen Commit mit der Nachricht "Refactored xyz subsystem.".

Bei größeren Änderungen sollten Sie die Richtlinie dev-branch-per-change beachten.