Böse Falle

Flattr this!

Vor längerer Zeit hörte ich eine Geschichte über einen Kollegen, der Subversion angeblich auf eine sehr seltsame Weise benutzt hat. Anscheinend wollte dieser die Quellcodeverwaltung zunächst gar nicht benutzen. Er tat es offenbar nur gezwungenermaßen, weil der Chef es gesagt hat und weil alle anderen im Team es auch taten. Also hat er munter drauflos programmiert, und am Ende des Tages (wörtlich gemeint, nicht als Metapher) dann seinen aktuellen Stand eingecheckt. Gemäß der Erzählung tat er dies allerdings „ohne Rücksicht auf Verluste“, wie man so schön sagt. Das heißt, er checkte den Code ein. Punkt.

Wo das Problem ist? Nun, wenn zwischenzeitlich bereits ein anderer Kollege etwas eingecheckt hat, sollte man in SVN zunächst den aktuellen Stand auschecken und mit den eigenen Änderungen mergen, bevor man einen Checkin macht. So bleiben die Änderungen der Kollegen erhalten und die eigenen werden hinzugefügt, was ja der Sinn von Teamarbeit ist. Zum Teil erzwingt SVN dieses Verhalten, aber das Mergen bleibt dem Entwickler überlassen. Der muss im Zweifelsfall entscheiden, wie gemergt wird, damit der Code aller Entwickler zusammenwachsen kann.

Das tat besagter Kollege … nun sagen wir mal … ausgesprochen eigenwillig.

Begriffsklärung

Subversion (SVN ist die Kurzform dafür) ist ein zentrales Quellcodeverwaltungssystem. Alle Aktionen erfolgen in direkter Kommunikation zum SVN-Server.

Git und Mercurial (Kurzform „Hg“) sind dezentrale Quellcodeverwaltungssysteme. Hier kann lokal gearbeitet und erst bei Bedarf mit dem Server kommuniziert werden.

Was bei SVN der Begriff „checkin“ bedeutet, ist in dezentralen Systemen auf zwei Befehle aufgeteilt, meist „commit“ und „push“ genannt.

SVN’s checkout wiederum wird in dezentralen Systemen durch die Kombination von „pull“ und „update“ (Hg) bzw. „fetch“ und „switch/checkout“ (Git) abgebildet. In Git und Hg kann man beide Aktionen auch durch einen Befehl ersetzen. und jetzt wird es etwas wirr: Was in Mercurial der Befehl „pull“ macht, heißt in Git „fetch“, während ein „git pull“ in Mercurial „hg pull -u“ lautet. Der Befehl „hg pull“ holt also nur die Änderungen vom Server ab, ändert aber nicht das Arbeitsverzeichnis, während „git pull“ beides in einem Schritt tut. Das ist eine wichtige Unterscheidung, wenn man in beiden Systemen arbeiten muss.

Manchmal ist das Problem kein Problem

Die obige Geschichte — mag sie nun stimmen oder nur üble Nachrede sein — muss nicht zwangsläufig zu einem Problem führen. Wenn alle Beteiligten an unterschiedlichen Dateien arbeiten, ist dieses Verfahren kein Problem, denn es gibt keine Notwendigkeit, einen „Merge“ durchzuführen. Ob das so ist, ist natürlich vom Programm und seinem „Layout“ abhängig, ebenso von der konkreten Aufgabenstellung. Handelt es sich um ein gut modularisiertes Programm, werden die Konflikte seltener auftreten, als bei einem Programm, bei dem die Verflechtungen der einzelnen Teile sehr hoch sind.

Was, wenn doch?

Aber wenn nun doch mal mehrere Leute an derselben Stelle arbeiten müssen, dann muss entschieden werden, wie die Zusammenführung abläuft. Sinnvollerweise sollten beide Änderungen erhalten bleiben, nur selten wird man die Stelle gemeinsam noch einmal überarbeiten müssen. Einfach zu entscheiden, dass meine Änderungen Vorrang haben, ist in meinen Augen ziemlich eigensinnig, ja egoistisch.

Und die Diskussionen, als die anderen im Team bemerkt haben, was da abläuft, müssen hart gewesen sein.

Bitte, Leute, macht so etwas nicht. Ein Team ist nur dann ein Team, wenn es eben nicht nur die Abkürzung von „Toll, ein anderer machts“ ist. Denkbar ist das natürlich nicht nur bei Subversion!

Ähnliche Artikel:

AuthorChristoph Jüngling

Selbständiger Softwareentwickler und Seminarleiter

Kommentar verfassen