Vorlesung Programmieren. Versionskontrollsysteme. Ziele von VCS. Versionskontrolle

Transkript

1 Vorlesung Programmieren Versionskontrolle Dr. Dennis Pfisterer Institut für Telematik, Universität zu Lübeck Versionskontrollsysteme Wie organisiert man die Arbeit an großen Projekten? Wie werden Änderungen an Dateien anderen zugänglich gemacht USB-Stick? Mail? Gemeinsames Dateisystem auf einem Server? Probleme Wie ordnet man Änderungen einer Person zu? Was wurde geändert? Wer hat sich was bei einer Änderung gedacht? Wie sah die Version davor aus? Lösung: Version Control Systems (VCS) Erfassung von Änderungen an Dokumenten oder Dateien Verknüpft Änderungen mit Zeitstempel und Benutzerkennung Benutzt für Quelltexte, Dokumente, Bilder, 2 Ziele von VCS Zugriff auf den Quelltext von mehreren Entwicklern koordinieren In Firmen arbeiten ggf. viele Entwickler an einem Projekt Manchmal sogar gleichzeitig an der gleichen Datei Protokollierungen der Änderungen Es kann jederzeit nachvollzogen werden, wer wann was geändert hat Wiederherstellung alter Versionen Rückgängigmachen versehentlicher/fehlerhafter Änderungen Archivierung/Markierung einzelner Stände Es kann auf eine spezielle Version zugegriffen werden (1.2, 2.5, ) Parallele Entwicklung an mehreren Versionen Pflege alter Versionen bei gleichzeitiger Entwicklung des Nachfolgers 3 1

2 Existierende VCS Lösungen (Auswahl) Revision Control System (RCS) Auf Dateibasis, nicht netzwerkfähig Concurrent Versions System (CVS) RCS-Nachfolger mit rudimentären Netzwerksupport Subversion (SVN) SVN-Nachfolger, flexibler, einfacher zu bedienen Weitere Systeme Git (verwendet für Linux-Kernel-Entwicklung) Mercurial Serena PVCS Version Manager Source Code Control System (SCCS) 4 Subversion Verwaltung in einem zentralen Repository Zugriff per ssh, lokalem Verzeichnis, HTTP/HTTPS, Globale Versionsnummer pro Projekt Entwickler übertragen Änderungen in/vom Repository Änderungen Änderungen Benutzer#2 Benutzer#1 Repository Änderungen Benutzer#n 5 Subversion Zu Beginn wird ein Projekt via checkout initial übertragen Erstellt eine lokale Arbeitskopie Repository Lokale Kopie: update Lokale Kopie Repository: commit Commit Update Benutzer#2 Benutzer#1 Repository Benutzer#n 6 2

3 Auschecken, editieren und commiten Mit svn co oder svn checkout einmalig eine lokale Arbeitskopie erstellen Datei(en) mit einem beliebigen Editor bearbeiten Mittels svn commit einchecken Mit -m wird eine Änderungsbeschreibung übertragen 7 Typische Commit-Meldung Oft der Fall, dass man Änderungen commiten will und die gleiche Datei wurde schon im Repository geändert Es muss zunächst die lokale Kopie aktualisiert werden 8 Lokale Kopie aktualisieren Wurde am gleichen Dokument in gleichen Abschnitten geändert, gibt es Konflikte Konflikte entstehen nur in lokalen Kopien, werden dort behoben und dann die Änderungen commited Wer zuerst commited gewinnt (commit early, commit often) 9 3

4 Darstellung von Konflikten Beide Änderungen sind enthalten und werden markiert Meine Änderungen sind zwischen <<<<<<<.mine und ======= Änderungen im Repository zwischen ====== und >>>>>.r# 10 Grafische Darstellung von Konflikten 11 Änderungen commiten: Neue Revisionsnummer 12 4

5 Kopie aktualisieren: svn update In die lokale Arbeitskopie werden die Änderungen zur aktuellen Revision übertragen 13 Subversion: Weitere Features Auschecken bestimmter Revisionen Verschieben von Dateien im Repository Branching und Tagging Uvm. Quelle der Grafik: Wikipedia (Subversion) 14 Verteilte Versionskontrollsysteme (am Beispiel von git) 5

6 Zentrales Repository oft problematisch Single point of failure Komplette Zerstörung bei Ausfall, Brand, etc. Häufig langsam (z.b. bei weltweiten Teams) Kein Arbeiten ohne Netzverbindung Historie nur auf Server verfügbar Commits nur online auf Server möglich Commiten erst in stabilen Zuständen möglich Ansonsten ist Code in Repository evtl. nicht compilierbar bzw. funktionsfähig Problem: Viele Änderungen pro commit Schwer verständlich, was genau geändert wurde Oft vergessen die Entwickler selbst, was sie getan haben Verteilte Versionskontrollsysteme Jeder Entwickler hat vollständiges Repository Ein Klon des initialen Repositories Enthält gesamte Historie des Projekts Auf lokalem Klon autonomes Arbeiten möglich Entwickler können Änderungen in entfernte Repositories pushen von entfernten Repositories pullen Änderungen (z.b. per Mail) austauschen und einspielen Zentrales VCS Änderungen Änderungen Benutzer#2 Benutzer#1 Repository Änderungen Benutzer#n 6

7 Verteiltes VCS Repository Repository Benutzer#1 Änderungen Benutzer#4 Repository Repository Benutzer#2 Benutzer#3 Verteiltes VCS Problem: Wie synchronisieren sich Entwickler, die gemeinsam an einem Projekt arbeiten Lösung: Häufig existiert per Konvention ein Master-Repository Repository Master - Repository Repository Entwickler pushen zum und pullen vom Master Repository Repository Repository Repository Versionsnummern in DVCS Problem: Kein zentrales Hochzählen der Versionsnummer möglich Lösung: Berechnung einer eindeutigen ID Kennzeichnet eindeutig einen Commit Auf Basis des Inhalts aller Dateien (SHA-1 Hashwert) Beispiel: 1a1ce14a54279c3ee107593f585d38f5d9de192d 7

8 Funktionsweise eines Repositories Entwicklung im Projektverzeichnis Hinzufügen von Änderungen in sog. Stagingarea Commit in lokales Repository Bildquelle: Staging-Area Manchmal bearbeitet man mehrere Dinge zur gleichen Zeit Zum Beispiel zwei Bugfixes Logisch sollten dies zwei Commits sein (Nachvollziehbarkeit) Hinzufügen von Änderungen zur Stagingarea Zur Auswahl der Bestandteile eines Commits Geänderte Dateien Änderungen an einzelnen Zeilen einer Datei Anlegen eines neuen Projekts 8

9 Arbeiten am Projekt Anlegen und Editieren von Main.java Inhalt von Main.java nach Editieren Aktueller Zustand 9

10 Main.java in Staging-Area hinzufügen Neue Datei hinzufügen / Zustand Commit der Staging-Area 10

11 Dokumentation hinzufügen Hinzufügen zur Staging-Area und commiten Zustand / Historie Editieren von Main.java 11

12 Zustand nach Editieren von Main.java Änderungen anzeigen Editieren von README.txt 12

13 Zustand nach Editieren von README.txt Änderungen anzeigen Alle geänderten Dateien commiten (-a) 13

14 Klonen eines (entfernten) Repositories Pushen Aliase für Repositories Repositories werden über URLs referenziert Einfacher: Kurze Aliase verwenden Häufig: origin für das Herkunftsrepository von dem geklont wurde Können anstelle der URL verwendet werden 14

15 Hinzufügen eines Aliases Verwendung von Aliasen Branching und Merging Häufig gibt es mehr als eine Entwicklungslinie Zum Beispiel Pflege alter Versionen Entwicklung eines neuen Features Fixen von Bugs Entwicklung der nächsten Version (D)VCS-Systeme unterstützen sog. Branches (Zweige) Zum Beispiel master (stabile Version) und develop (Entwicklungsversion) Zusammenführen zweier Zweige heißt Merging Bildquelle: 15

16 Beispiel für DVCS-Nutzung Bildquelle: Erstellen eines Branches Nach Erstellen wechseln in den Branch Verändert das Projektverzeichnis Bildquelle: Arbeiten im develop Branch 16

17 Wechseln zu master Branch Mergen von develop in aktiven master Historie 17

18 Git Literatur Grundlegendes Einrichtung unter Linux Einrichtung unter Windows Einrichtung unter Mac Keyerzeugung mit Putty unter Windows Public und Private Key Public Key ssh-dss...nslq+jfoojbc9wx3feu350gua== dsa-key Private Key (File Save private key...), niemals weitergeben PuTTY-User-Key-File-2: ssh-dss Encryption: none Comment: dsa-key Public-Lines: 10 AAAAB3NzaC1kc3MAAA...BWQr4uWWIQcg1fmZCNsLQ+JfoOjBC9WX 3fEu350g UA== Private-Lines: 1 AAAAFF47e/CjUkKMHhoRneJECul28ZEP Private-MAC: 946ed998c1c5bcd5a5b69e18736c12a79562c03a Putty Agent starten: pageant.exe private-key.ppk 18

19 Installation von git via cygwin Bei der Installation git auswählen In der Systemsteuerung Umgebungsvariable GIT_SSH anlegen Inhalt soll auf plink.exe von putty zeigen Beispiel: GIT_SSH=c:\Windows\plink.exe Keyerzeugung mit Putty unter Unix Ausführen: ssh-keygen -t dsa Privater Schlüssel liegt in ~/.ssh/id_dsa Öffentlicher Schlüssel in ~/.ssh/id_dsa.pub Zusammenarbeit Windows- und Unix Problem: Verschiedene Zeilenumbrüche Aktivieren automatischer Konvertierung git config --global core.autocrlf input Weitere Informationen: 19

20 Literatur SVN TortoiseSVN GIT A successful Git branching model