Digitalist #1 Git
- Mike Kunze

- 24. März
- 3 Min. Lesezeit
Aktualisiert: 7. Mai
Den älteren Programmierern, Internetprofis und Digitalisierern sind bestimmt noch SVN und CVS ein Begriff, alle anderen, vor allem die, die nach 2005 in die Informatik gekommen sind, kennen wahrscheinlich nur Git und haben von SVN vielleicht mal gehört.
Eigentlich geht es bei jeder Technologie immer darum, dass man seine Arbeit versioniert ablegen möchte, ohne die gleiche Datei mehrfach in verschiedenen Versionen unter verschiedenen Namen abzulegen.Der eine oder andere kennt sicher noch die Nachsilben "_final" oder "_final_1", "_final_2". Das wollen wir zwar nicht, aber es ist immer eine nette Anekdote zum Erzählen aus der Vergangenheit.
Hier ein kurzer historischer Abriss der Versionsverwaltungswerkzeuge, nur der Vollständigkeit halber.
SCCS (Source Code Control System) | 1972 |
RCS (Revision Control System) | 1982 |
CVS (Concurrent Versions System) | 1990 |
PVCS (Polytron Version Control System) | Mitte der 1980er bis 1990er |
Subversion (SVN) | 2000 |
Perforce | 1995 (mit stärkerer Verbreitung in den 2000ern) |
Git | 2005 |
Mercurial | 2005 |
GitHub | 2008 |
GitLab | 2011 |
Bitbucket | 2008 |
Plastic SCM | 2005 (populärer in den 2010ern) |
Heute geht's um Git und ein paar Dinge, die man vielleicht erwähnen sollte. Außerdem ein paar Tipps, die jeder kennen sollte, bevor er mit einer "Meinung" in eine Diskussion geht.
Git-Arbeitsweise
Die Arbeitsweise ist branchorientiert. Das heißt, ihr erstellt erst eine Kopie von einem Branch, arbeitet darin und führt den Branch wieder zurück in den Ursprungs-Branch.
Wenn ihr etwas ändert, schreibt ihr es zunächst nur in eurem Branch. Das ist wie speichern.
Commit-Message
Das ist eine Nachricht an euer Zukunfts-Ich. Lasst ihm eine Notiz da, damit ihr wisst, was in der Vergangenheit passiert ist.
Pushen
Alles, was ihr committet habt, könnt ihr auf das zentrale System pushen. In euren eigenen Branch. Da könnt ihr fast machen, was ihr wollt, aber das ist eigentlich auch egal.In der Commit-Message sollten auf jeden Fall Notizen enthalten sein, mit denen ihr später wieder wisst, was ihr getan habt und warum.
Mergen
Das Zusammenführen von Branches (Arbeitsständen) nennt man Mergen. Das passiert immer über einen Merge Request. Da siehst du, ob es Konflikte gibt und welche Unterschiede zwischen Ursprung und Änderung bestehen.
Das waren die Grundbegriffe, die ihr kennen müsst. Jetzt kommen wir zu etwas mehr Details. Später gehe ich noch detaillierter auf die einzelnen Themen ein, aber nun wirklich nur die Mindestanforderungen und etwas drüber.
Jetzt wird es spannend, denn jetzt sollten ein paar Sorgfaltsregeln greifen.Oft habe ich erlebt, dass es an der Sorgfalt hapert. Immer wieder fallen dann Sätze wie "Das braucht man nicht". Ich sage euch nach über 15 Jahren Git-Erfahrung: Doch, man braucht es.Lasst euch keinen Schmu erzählen.
Wir fangen mit dem Branch-Namen an. Wie soll unser Branch eigentlich heißen? Gibt es Regeln oder Best Practices? Klar, es gibt auch ein wenig Freiraum. Der Branch-Name sollte eindeutig und erklärend sein. Bewährt hat sich die Ticketnummer. So simpel, so eindeutig. Und dann die Commit-Message. Oh mein Gott, da gibt es Best Practices, aber offensichtlich glauben viele, das das nur Ideen sind. Nein,
Subjectline //(maximal 50 Zeichen)
Leerzeile
Commit-Message //(Umbruch nach ca 72 Zeichen)
Leerzeile
FooterAlles andere ist "Schmu" und das hier ist jetzt wirklich nur die Mindestanforderung.
Subjectline ist die Zusammenfassung und ja 50 Zeichen müssen reichen.
Commit-Message ist wie schon erwähnt die Nachricht an dein Zukunfts-Ich. Darum sollte sie auch nicht in der Vergangenheit geschrieben sein, sondern im "Will-Future"
Will-Future: unabwendbare Ereignisse – zukünftiges Geschehen hängt nicht von persönlichen Entscheidungen ab
Wenn der Branch gemerged wird, passiert das, was in der Commit-Message beschrieben ist. Die Codeänderung hat vorher keine Auswirkung.
Der Footer erklärt, wie die Tickets damit zusammenhängen.
Resolves: [Ticket-Nr.]
// (hat meistens die gleiche Ticketnummer wie der Branchenname)"See also" oder "Relates": [Ticket-Nr.], [Ticket-Nr.]
// (alle anderen Tickets eben, die hierdurch betroffen sind)Beherzigt man diese paar einfachen Dinge ist man schon auf einem Guten Weg.
Mehr gibt es dann bald und dann schauen wir etwas genauer hin.

