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:
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:
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:
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:
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:
Branches sind tolle Features des Versionsverwaltungssystems, allerdings ersetzen sie nicht gute Kommunikation!! Hier sind einige Eckpunkte, die immer abgeklärt sein sollten:
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:
Kommunikation ist das A und O!
Alle Branches müssen im Repository-Verzeichnis im unter /branches/ abgelegt werden.
Grund:
Grund:
Statt „Personenbezogenen“ branches sollten eher „Featurebranches“ erstellt, und auch dementsprechend benannt werden. Gründe:
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:
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:
Grund:
Vor einem Merge nach Trunk wird zuerst ein Merge vom Trunk in den Branch gemacht. Gründe:
Ist die Trunk in den Branch gemerget, sollte das Projekt kompiliert und getestet werden, wenn möglich auf jeder Plattform!
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:
Haltet eure Arbeitskopie „über Nacht“ oder bei längerer Abwesenheit sauber. Gründe:
Für Fragen und Rückmeldungen, meldet euch bitte in diesem Forum: http://forum.proggen.org/viewtopic.php?f=66&t=2395