Commits sollten nicht zu selten gemacht werden. „Code-Bombs“, also große Änderungen in nur einem Commit sollten vermieden werden. Stattdessen sollte ein Commit der logischen Einheit einer Änderung entsprechen.

Gründe:

• Das Repository ist auch ein Ort für Backups. Missgeschicke können schnell passieren; wenn zu lange nicht commitet wird, sind die Verluste groß.
• Nachvollziehbarkeit. Repräsentiert ein Commit auch nur eine Änderung, kann man genau Nachvollziehen wann was warum geändert wurde. Dies ist sehr nützlich beim Debuggen, viele Tools können damit sehr gut arbeiten (svn blame, git bisect)
• Frühes Feedback. Commitet man oft, sehen die anderen Entwickler in welche Richtung man geht. Das ist von großem Vorteil, da sie sich einerseits auf „das was kommt“ einstellen können und andererseits früh genug reagiert werden kann, wenn die Entwicklung in die falsche Richtung geht (also totale Griffe ins Klo vermieden werden).

Commits einer Person sollten nur von seinem Account aus geschehen. Auch wenn sich zwei Entwickler persönlich kennen, sollten sie keinesfalls Accountdaten aneinander weitergeben und für den anderen Commiten.

Gründe:

• Passwörter zu übergeben ist immer ein Sicherheitsrisiko. Egal ob auf Papier, mündlich, per ICQ/Skype/whataever, per PN oder per E-Mail, es ist von Natur aus ein Angriffspunkt.
• Nachvollziehbarkeit. Es ist sehr nützlich, wenn zu einer Änderung auch der Autor genannt wird, zum Beispiel für Rückfragen. Das kann auch zur Klärung von rechtlichen Fragen nützlich sein.
• Vertrauen ist gut. Sogar sehr gut. Allerdings sollte man das Vertrauen eher auf andere Bereiche verlagern, denn in diesem Fall ist das Vertrauen nicht notwendig und sogar kontraproduktiv.

Commit-Messages sollten in englischer Sprache (genauso wie Code und Kommentare) geschrieben werden. Sie sollten wie folgt gestaltet werden:

Eine kurze (wenns geht weniger als 50 Zeichen) Zusammenfassung der Änderung in der ersten Zeile.

Eine etwas detailliertere Beschreibung der Änderung, evtl. mit Dateinamen.
Diese sollte informativ sein, und evtl. auch Gründe für die Änderung enthalten, allerdings darf man sich hier nicht im Detail verlieren oder die Dokumentation des Codes hierhinein verlagern.

Schlecht: „Changed search function“
Gut: „Changed search function: abort search if element has been found. this saves a lot of cpu time if the search term is at the beginning.“
Schlecht: „Changed search function: added break; statement in line 223, moved switch command a little more to the top, added comment at line 214, introduced new variable term_found…“

Achtung: würde die detaillierte Beschreibung das Gleiche sein wie die Kurzbeschreibung (also die Kurzbeschreibung schon ausreichen um die Änderung zu beschreiben), so kann man die detaillierte Beschreibung natürlich auch weglassen.
Anmerkung: Gerade dieser Punkt ist nicht Streng auszulegen. Man sollte viel mehr einen guten Stil entwickeln Changelogs zu schreiben, und dieser Stil sollte im Projekt beibehalten werden. Diese Regeln sind nur eine Anregung, wie so etwas aussehen könnte.

Gründe:

• Nachvollziehbarkeit. Man sollte immer Wissen, warum eine Zeile wo steht. Hier helfen gute Commitnachrichten mit gut geordneten Commits sehr.
• Entwickler haben per Definition zu wenig Zeit (nicht wenig sondern zu wenig). Wenn sie sich das log ansehen um nachzuvollziehen, was denn geändert wurde, wollen sie manchmal nur einen Überblick haben. Hier reicht die erste Zeile.
  Wollen sie es genauer wissen, und auch nachvollziehen warum etwas geändert wurde, reicht ein Blick in die Detailbeschreibung.
  Wollen sie es ganz genau wissen (z.B. auf der Suche nach einem Bug…) können sie sich immer noch das Diff ansehen.

Das ist die goldene Regel. Der Trunk muss immer kompilierbar bleiben, vor jedem Commit sollte das Projekt kompiliert werden und Tests (if any) durchgeführt werden.
Dies richtet sich vor allem an IDE-Benutzer: Die IDE versucht oft schlauer zu sein als es gut wäre, und sieht Dateien die SVN nicht sieht. Bitte zieht in Erwägung das Projekt auf der Kommandozeile, mit nur den Dateien aus dem SVN zu bauen.

Einschränkung: Das Projekt ist dafür ausgelegt auf mehreren Plattformen zu laufen. Man kann nicht erwarten, dass jeder Entwickler vor jedem Commit den er macht das Projekt auf jeder Plattform kompiliert. Erwarten kann man allerdings, dass das Projekt auf der Plattform des Commiters kompiliert.
Vor allem vor einem Merge eines Featurebranches nach Trunk sollte man das Projekt auch auf anderen Plattformen kompilieren!

Gründe:

• Der Trunk ist das Aushängeschild des Projektes, denn wenn sich User dafür interessieren, werden sie statt einer sehr wahrscheinlich veralteten (Release-?)Version den Trunk auschecken. Checken die User eine unkompilierbare Version aus, wirft das ein sehr schlechtes Licht auf das Projekt
• Ihr arbeitet nicht alleine. Die anderen Entwickler werden nicht gut auf euch zu sprechen sein, wenn sie ihre Arbeitskopie updaten und auf einmal Kompiliert das Projekt nicht mehr, und zwar aus einem Grund den nicht sie zu verantworten haben.

Entwicklung sollte in Featurebranches geschehen. Nur kleine Bugfixes sollten direkt auf den Trunk commitet werden, größere Features und Module sollten immer auf eigenen Branches entwickelt werden und dann (umsichtig!) auf den Trunk gemerget werden. Es sind auch dabeu einige Regeln zu beachten, diese sind unter dem Punkt Branches zusammengefasst.

Gründe:

• Um ein Feature zu erstellen ist es oft notwendig auch mal gröbere Umbauarbeiten in Kauf zu nehmen. Das ist völlig normal. Diese Umbauarbeiten auf dem Trunk durchzuführen ist allerdings nicht akzeptabel, siehe „Don't break the build!“.
• Nachvollziehbarkeit. Werden alle Änderungen nur auf einem Branch durchgeführt, so zeigt das log natürlich nur diese Änderungen. Commitet man gleich nach Trunk, so sind im Log und im Diff Commits zu verschiedensten Themen sichtbar. Das erschwert das Lesen.
• Ihr arbeitet nicht alleine, auch andere Entwickler arbeiten an Themen. Ihr solltet ihnen mit eurer Arbeit nicht ins Handwerk pfuschen.

Branches sind tolle Features des Versionsverwaltungssystems, allerdings ersetzen sie nicht gute Kommunikation!! Hier sind einige Eckpunkte, die immer abgeklärt sein sollten:

• Wer arbeitet woran?
• Wo gibt es überschneidungen? Wie löst man diese?
• Wer arbeitet an der gleichen Datei?
• Wie passt das Feature in das gesamtkonzept des Projekts?

Zurzeit gibt es nur das Forum, ihr könnt allerdings mit euren Entwicklern auch E-Mail Addressen austauschen, mit ihnen per IM-Systemen in Kontakt treten oder auch im RL mit ihnen Reden. Das wichtigste ist: kommuniziert!

Grund:

• Vermeidung von Missverständnissen, Merge-konflikten und auch sozialen Konflikten.
• Viele Fehler in der Technik, in Firmen, in Software, und sehr vielen anderen Bereichen gehen auf mangelnde Kommunikation oder Missverständnisse zurück. Diese sind Vermeidbar!

Kommunikation ist das A und O!

Alle Branches müssen im Repository-Verzeichnis im unter /branches/ abgelegt werden.
Grund:

• Das ist Standardverhalten, und wird von SVN Usern und manchen Tools so verlangt.

Grund:

• Es kann durchaus passieren, dass das Projekt wegen eures Features nicht kompiliert. Das macht nichts, spart euch die Zeit es jedes mal kompilieren und bessert den Fehler lieber im nächsten Commit aus.

Statt „Personenbezogenen“ branches sollten eher „Featurebranches“ erstellt, und auch dementsprechend benannt werden. Gründe:

• Zuständige Entwickler können wechseln, das Feature bleibt.
• Will jemand den Branch eines Features auschecken, so muss er ersteinmal Wissen wer dafür zuständig ist. Das ist nicht nur für Außenstehende manchmal gar nicht so leicht.
• Personenbezogene branches fördern Territorialverhalten

Diese Regel ist eine Seite der nächsten Regel. Hat man Feedback, oder will man Änderungen einpflegen so sollte man diese dem Zuständigen mitteilen, und evtl. als Patch schicken. Natürlich kann der Zuständige das direkte Commiten auf seinen Branch erlauben. Hier ist Kommunikation wichtig. Gründe:

• Stellt euch vor, ihr schreibt gerade einen Aufsatz. Jemand reißt euch den Zettel aus der Hand, schreibt selbst etwas hin und wirft den Zettel vor der Nase hin. Das ist einfach unhöflich.
• Ihr könnt die Auswirkungen eures Commits vielleicht nicht so gut einschätzen wie der Verantwortliche, der sich schon längere Zeit damit beschäftigt hat.

Diese Regel ist die andere Seite der vorherigen Regel. Seid ihr selbst Verantwortlich für einen Branch, vermeidet Begriffe wie „mein Branch“ und „dein Branch“, erlaubt (sinnvolle!) Änderungen durch Andere, und kommuniziert eure Fortschritte. Gründe:

• Ihr seid zwar Verantwortlich für ein Feature, doch ihr „besitzt“ es nicht, es „gehört“ dem Projekt. Begriffe wie „meins“ oder „deins“ sind hier nicht angebracht.
• Terretorialverhalten verschlechtert die Beziehungen zwischen den Entwicklern. Obwohl jeder seine „Privatssphäre“ braucht, sollte man immer Kontakt zu seinen Mitentwicklern behalten und sich nicht als Einzelkämpfer sehen. Alle Entwickler sitzen im selben Boot.
• Feedback ist sehr wichtig. Feedback hilft euch Fehler früh zu erkennen und Vorschläge einzubauen. Baut ihr einen Zaun um euer Grundstück, fühlen vielleicht manche, dass Feedback nicht gewünscht ist.

Grund:

• Ihr solltet einen Branch nie zu weit weg driften lassen. Regelmäßige Merges helfen dabei, Konflikte frühzeitig zu erkennen und relativ leicht zubeheben. Das erleichtert das zurückmergen nach Trunk sehr.

Vor einem Merge nach Trunk wird zuerst ein Merge vom Trunk in den Branch gemacht. Gründe:

• Probleme werden erkannt und gleich behoben, und setzen nicht den Trunk außer Gefecht.
• Der Merge nach Trunk wird zu einer „trivialen Operation“.

Ist die Trunk in den Branch gemerget, sollte das Projekt kompiliert und getestet werden, wenn möglich auf jeder Plattform!

• Grund: Siehe Don't break the build!. Bei einem Merge nach Trunk kann viel schieflaufen, und das kann die Trunk ziemlich kaputt machen. Das muss nicht sein.

Zu beachten: merget man den Branch zurück in die Trunk, so tut man das mit „svn merge –reintegrate“. Danach ist der Branch allerdings TOT! Man sollte darauf keine sinnvolle Arbeit mehr durchführen.
Möchte man den Branch aus irgendwelchen Gründen behalten, so sollte man den alten Löschen, und einen neuen (evtl. mit gleichem Namen) ausgehend von der aktuellen Trunk machen. Hier ein Link dazu: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html

Organisiert eure Arbeit in Einheiten, am Besten solche die einem Commit entsprechen. Der Arbeitsablauf sieht so aus:

svn update <- neueste Änderungen holen
Änderungen machen
Eure Änderungen nochmal betrachten: svn status, svn diff
svn update <- Änderungen holen, die evtl. während eurer Arbeit gemacht worden sind
Mergekonflikte (if any) beheben, dann svn resolve
svn commit <- Erst jetzt wird commitet

Hier ein Link dazu: http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html

Gründe:

• Siehe oben

Haltet eure Arbeitskopie „über Nacht“ oder bei längerer Abwesenheit sauber. Gründe:

• Es ist menschlich, wenn ihr nicht sofort wisst was ihr als letztes getan habt. Ist die Arbeitskopie sauber, so hilft da das Log weiter.
• In der Zwischenzeit könnte es Änderungen gegeben haben. Dabei können Mergekonflikte entstehen, die leicht vermieden werden können.
• Backup, Siehe oben

Für Fragen und Rückmeldungen, meldet euch bitte in diesem Forum: http://forum.proggen.org/viewtopic.php?f=66&t=2395