Archiv vom März 4th, 2013

Tags:

Jeder weiß, daß man Dokumente, in denen viel Hirnschmalz in wenig Text verpackt ist1, in einem Revision Control System hält. Ich habe früher CVS für größere Projekte und RCS für Kleinkram2 verwendet.

For ein paar Jahren bin ich dann auf git umgestiegen: Neben dem einfachen Einrichten des Repository3 macht vor allem das leichte und schnelle Branchen Spaß. Zugegeben, git hat auch seine Schwächen, und die Bedienung ist nicht immer einfach4.

Trotzdem überwiegen in meinen Augen zumindest gegenüber SVN und CVS (und natürlich RCS) die Vorteile. Vor ein paar Tagen bin ich zufällig über einen Blog-Eintrag von Vincent Driessen gestolpert, der dem Werkzeug git sozusagen als Überbau noch einen Prozeß oder einen Satz Richtlinien hinzufügt -- Anweisungen, wann man welche Branches erzeugen soll, und wohin sie gemerget werden. Das Modell gefällt mir auf Anhieb recht gut, und weil es dazu auch ein Tool gibt, das das Einhalten des Prozesses stark vereinfacht, werde ich meine Repositories demnächst wohl nach und nach umstellen.

Vincents Modell hat natürlich auch Kritiker, und wer tiefer einsteigen will, sollte sich die Diskussion zu Jeffs Blog-Eintrag durchlesen. Wahrscheinlich am meisten nachgedacht hat Adam Dymitruk. Die Feinheiten seines Modells sind für mich zu dieser späten Stunde definitiv zuviel, aber mir gefällt die Idee, Feature Branches unabhängig zu halten, so daß man jedes Feature jederzeit wieder ausbauen kann.5

Edit: HTML an falscher Stelle
Edit 2: Typo

  1. z.B. Source Code und Konfigurationsdateien []
  2. z.B. Dateien aus /etc []
  3. ja, ich benutze normalerweise auch lieber deutsche Begriffe, aber heute lasse ich das aus gutem Grunde mal sein: wenn man gut eingeführte termini technici übersetzt, versteht am Ende niemand etwas []
  4. manche Kommandos muß ich heute noch immer wieder nachschlagen, checkout -b vergesse ich regelmäßig, wenn ich es nicht oft genug benutze []
  5. jedenfalls bis zum nächsten Release []
2 Kommentare