Einführung git Flashcards
Vermeidbare Probleme bei der Arbeit mit Daten, Dokumenten, Programmcode, Belegarbeiten:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)
- Letzte Version gelöscht
- In welcher Datei befindet sich der letzte Arbeitsstand
- welche Änderungen wurden vorgenommen
- Kontrolle einer älteren Version nicht möglich
Probleme im Team:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)
- Welche Version in einer lokalen Kopie passt zu der anderen Version einer anderen einer lokalen Kopie
- Änderungen überschreiben
- Änderungsprotokoll
Motivation:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)
-gemeinsames Arbeiten an Dokumenten
-bei Änderungen sollen abhängige Dokumente konsistent gehalten werden
-Entwicklung der Dokumente nachvollziehbar mit Möglichkeit auf ältere Stände zurück gehen zu können
-Softwareentwicklung ohne Kenntnisse zu Version Control Systems praktisch
unmöglich
Ansatz:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)
- Alle gemeinschaftlich genutzten Dokumente (bei Teamarbeit) und
- Alle sich ändernden Dokumente, Quellcodes, usw. werden in einem (gemeinsamen) Datenspeicher (Begriff: Repository ) gehalten
- jeder Nutzer erhält entsprechende Rechte zum Zugriff auf die Dokumente indem Datenspeicher
Standardverhalten:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)
-Sally und Harry arbeiten am selben Dokument A zur selben Zeit.
-Beide führen verschiedene
Änderungen an ihren lokalen Kopien durch.
-Harry speichert seine Änderungen als Erster.
-Sally speichert ihre Änderungen ebenfalls,
aber kurze Zeit später.
-Harrys Änderungen sind für immer verloren,
weil überschrieben.
https://ibb.co/pX1wW1D
Lösungsmöglichkeit 1: Sperren
Versionsverwaltung
WIESO, WESHALB, WARUM?
Mögliche Nachteile -Entsperren vergessen -lange Wartezeiten -Wenn zwei Nutzer ein Dokument an verschiedenen Stellen ändern möchten, könnten sie dies auch ohne Sperren gleichzeitig tun
Lösungsmöglichkeit 2: Kopieren Ändern Mischen:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)
https://ibb.co/7V6GmP6
Wertung
-Durch Mischen der Versionen können Sally und Harry (resp. mehrere Nutzer) auf
einem Dokument schreiben, aber:
-Was, wenn sich Sallys und Harrys Änderungen überlappen?
=> Konflikt
Konflikte
- werden automatisch erkannt
- können mit entsprechenden Werkzeuge angezeigt werden
- endgültige Änderungen müssen durch einen Nutzer manuell gewählt werden
=> evtl. Absprachen mit anderem Nutzer erforderlich
Praxis
Die meisten nebenläufigen Änderungen an einem Dokument sind konfliktfrei
=> entsprechendes System: Versionsverwaltung (VCS)
z.B.
CVS , Subversion SVN ), git
git (Allgemeiner Überblick (1/4))
Software zur ( Versionsverwaltung von
- Dokumenten,
- Quelltexten,
- ganzen Projekten und derer Metadaten,
- sowie Binärdaten (s.a. Git LFS)
-Betriebssystemunabhängig und agnostisch zur Arbeitsumgebung
git speichert im “unsichtbaren“ Ordner git des Projektverzeichnisses, dem
Repository , dafür u.
-die versionierten Inhalte zerlegt in Form von Binärdaten ( objects
-eine vollständige Historie der gespeicherten Arbeitsstände
-Metadaten & Konfiguration
git (Allgemeiner Überblick (2/4))
Bearbeitungsstände werden durch sog. Commits gekennzeichnet und
Bearbeitungszweigen, den sog. Branches zugeordnet.
-„Absatz zur DSGVO
-„Formatierung des Dokuments
-„Klick Event zur Karte hinzugefügt.“
Sie werden so Teil einer nachvollziehbaren Versionshistorie (Log, o.a. History
und erhalten eine
-selbstgewählte Beschreibung (Beispiele siehe voriger Punkt),
-Metadaten (Autor, beteiligte Autoren, Zeitstempel, …)
-und einen universal eindeutigen, unabänderbaren Hash Wert (SHA).
Der Hash Wert errechnet sich aus Commit Inhalt, Datum und bisheriger Historie.
Commits können über ihren SHA Identifikator aus der Historiewiederhergestellt werden.
git (Allgemeiner Überblick (3/4))
Branches , also Bearbeitungszweige, können individuell „ausgecheckt“,
unabhängig voneinander weiterentwickelt und
schließlich wieder per mergezusammengeführt werden.
Als Hauptzweig der Entwicklung hat sich per Konvention der Name master
durchgesetzt.
Nebenzweige die zur Implementierung einer Funktion dienen, bezeichnet man
als „ Feature branches
- include dsgvo
- text formatting
- map click event
Jedes Git Repository eines Projektes ist „beschreibbar“. Änderungen müssen
nicht zwangsweise an eine (zentrale) Instanz übermittelt werden.
-Master Master Replikation
git (Allgemeiner Überblick (4/4))
Commits können zwischen beliebig vielen Repositories ausgetauscht werden.
- Bei lokalen Daten spricht man hier vom lokalen Repository,
- entfernte Repositories werden als Remotes bezeichnet.
Ein neues Repository von einem bestehenden Stand abzuleiten bezeichnet manals „ klonen”
Ein Repository von einem bestehenden abzuleiten, um dieses abgeleitete (zumindest temporär) als Haupt Repository zu bearbeiten, bezeichnet man als
“forken”
Per Konvention beschreibt Origin ein zentrales, entferntes Repository, von dem
der lokale Klon abgeleitet wurde. Upstream beschreibt ein entferntes Repository
mit gewisser “Autorität“, zumeist verwaltet durch die ursprünglichen Autoren
einer Entwicklung.
-Bspw. kann ein Team Repository als Upstream , ein eigener Fork als Origin bezeichnet werden.
git (Nomenklatur) auch deutsch :D für welche Wörter sind wichtig!
Working tree
Arbeitsstand im Projektverzeichnis inkl. aller lokalen Änderungen
Index,Staging area –
„Bühne“ um Änderungen für den nächsten Commit vorzumerken
Commit versionierter Arbeitsstand (Snapshot ) mit eindeutigem Identifikator (SHA) und Beschreibung
Branch
Bearbeitungszweig, i.d.R. bezeichnet master den Hauptzweig der Entwicklung
HEAD
Zeiger , der auf den aktuellen lokalen Branch zeigt (so weiß git , welcher
Bearbeitungszweig gerade aktuell ist)
Tag
markierter Commit um lauffähige Zwischenstände einer Entwicklung zu kennzeichnen
History, Log
Logbuch aller Änderungen in einem Repository
Remote
entfernte Repositories , sowohl auf anderen Computern oder in einem anderen
Verzeichnis;
typisch origin für eigenen zentralen Server oder Fork , upstream für den ursprünglichen Autor oder Maintainer
git (Werkzeuge)
Clients
- Kommandozeile
- GUI Clients, z.B. GitKraken , SmartGit , Atlassian Source Tree ,
- IDE Integration: Egit Eclipse ), NetBeans Plugin
- Git integriert in die Dateiverwaltung des Betriebssystems: TortoiseGit
Cloud Hosting
- GitHub.com, BitBucket.com, GitLab.com uvw . (evtl.
- GitLab Server der Fakultät (Open
Prinzip Git
Erste Schritte und Kommandos (lokal 1)
https://ibb.co/m4VGDBy
pull/push -> Neue Version anlegen: commit
und mit Kurztext beschreiben(commit message) ->Dateien für neue Version vormerken: add -> Dateien ändern/anlegen
Erste Schritte und Kommandos (lokal 2)
https://ibb.co/BjCkWvS
Konsolenkommandos
git konfigurieren
-Identität festlegen
>git config global user.name “Sally Wonderful
>git config global user.email sw@example.com
Kontrolle
>git config list
Hilfe
>git help
>git help kommando
z.B.
>githelpconfiggit
alternativ mit TortoiseGit
git konfigurieren mittels TortoiseGit (Fortsetzung)
Erste Schritte und Kommandos (lokal 3)
https://ibb.co/L90RzVs
Erste Schritte und Kommandos (lokal 4)
https://ibb.co/Mg0qByN
-Lokales leeres git Repository anlegen 1/2)
aktuelles Verzeichnis wird zu leerem git Repository
z.B. Laufwerk
D: Ablage s#####
Erste Schritte und Kommandos (lokal 5)
https://ibb.co/g4YwXm4
Lokales leeres git Repository anlegen 2/2)Laufwerk
D: Ablage s#####
In dem angelegten Repository wurde automatisch ein
Entwicklungszweig ( branch ) angelegt, der sog.
master branch
Erste Schritte und Kommandos (lokal 6)
https://ibb.co/JmQ1TmZ
- Dateien/Verzeichnisse wie gewohnt bearbeiten/anlegen
- Wenn sinnvoll: Änderungen für nächste Version vormerken
-neue Version erstellen
auf einzelner Datei oder ganzem Ordner
Erste Schritte und Kommandos (lokal 7)
https: //ibb.co/hZDWJ7n
- Commit Meldungsfenster mit Hash Wert der Version
-Historie anzeigen TortoiseGit > Show log
Erste Schritte und Kommandos (lokal 8)
https://ibb.co/BrNwxDp
-Änderungen anzeigen
TortoiseGit > Diff
-aktuell bearbeitete Version
umschalten switchen
TortoiseGit > Show log >
Checkout to this
Arbeiten im Team
vereinfacht
https://ibb.co/KKLVb9f
zentrales ->liegt im GitLAb
git Repo
BARE
Harrys -> pull / push
lokales git
Repo
Sallys -> pull / push
lokales
git Repo
->Neue Version anlegen: commit und mit Kurztext beschreiben (commit message)
Index Staging area
-> Dateien für neue Versionvormerken: add
Arbeitsverzeichnis
-> Dateien ändern/anlegen
Arbeiten im Team
Prinzip:
https://ibb.co/x1Btvnr
Prinzip
Arbeiten mehrere Entwickler gleichzeitig an einem Projekt,
entwickeln sie parallel => das Projekt verzweigt
Arbeiten im Team
Remote git Repository in lokales Repository kopieren:
https://ibb.co/xMFznPq
Remote git Repository in lokales Repository kopieren
im Zielverzeichnis: git clone
Arbeiten im Team
Neue/aktuelle Version vom remote Repository holen
https://ibb.co/9wSjdWW
Neue/aktuelle Version vom remote Repository holen und mit der eigenen aktuellen mischen
Der eigene Workspace darf keine Änderungen haben, die noch nicht committed
wurden!
TortoiseGit > Pull..
Arbeiten im Team
Hochladen der eigenen aktuellen Version ins remote Repository und
Hochladen der eigenen aktuellen Version ins remote Repository und
mischen (1)
-nur möglich, wenn lokales Repository auf aktuellem Stand
=> evtl. vorher pull erforderlich
-Konflikte werden angezeigt und müssen manuell behoben werden
> git push url
=> url ist bei uns der zentraleVerzeichnisname von origin
Arbeiten im Team
Konflikte
https://ibb.co/xMFznPq
Konflikte
- Beim Mischen können Konflikte auftreten => Push wird verweigert
- Ursache : Es gibt in beiden Versionen Änderungen an der gleichen Stelle
- Konflikte ansehen : Show git kennzeichnet die Konflikte in der Datei selbst
Lösung :
1.Pull durchführen
2.lokal Konflikte manuell beheben
=> Ersetze alle markierten Teile durch den gewünschten Text.
Branches: Basiskommandos
https://ibb.co/BNKrb1B
-Zunächst: Betrachtung lokales Repository
-Jedes neue Feature (Arbeitspaket) soll nicht im master branch , sondern in einem
eigenen Zweig entwickelt werden.
Branches: Basiskommandos Tortoise
https://ibb.co/3YjCYSg
Branch anlegen und hineinwechseln
Branches: Basiskommandos Tortoise
https://ibb.co/FVcvVhp
Änderungen vom lokalen Branch ( hier : Aufgabe9_ST_Collect ) sollen in den lokalen master branch zurückgeführt werden merge
Workflow
im Team Übersicht
Leiter Implementierung jedes Teams
-legt in der GitLab Gruppe des Teams einen Fork des ES-Template Projektes als Teamprojekt an
Jedes Teammitglied führt einmalig folgende Schritte durch
- meldet sich im GitLab an ( https://KIS5 ) und navigiert über
- Groups > Explore Groups > Lehrgebiete > G374 GI Applikationsentwicklung Master zu seinem Team hier liegt das durch die Leiter Implementierung erstellte Projekt Template, dessen URL mittels Clone zu kopieren ist
-führt die Konfiguration durch (Folie 15/16);
als Remote URL ist die im vorigen Schritt kopierte URL einzutragen
Die Mitglieder jedes Teams
1 clonen ihr Team Repository in ein lokales Arbeitsverzeichnis,
2 legen Feature Branches an und arbeiten bis zur Fertigstellung nur in diesen
3 führen lokal regelmäßige commits lauffähiger Versionen durch,
4 holen das Team Repo in den lokalen Master Branch pull
5mischen den (aktualisierten) lokalen Master mit dem Feature Branch merge
6 laden den Master in das zentrale Repo push ), evtl. Konfliktbeseitigung mithilfe/durch den Leiter
Implementierung
Workflow im Team
Übersicht
https://ibb.co/zZrR5Sw
Workflow im
Detail: GitLab Erster Start (1) und Start (2) und Start (3) und Start (4)
Nach der Anmeldung
https://ibb.co/F7bsZXq
Zu den Projekt Templates GI App browsen
https://ibb.co/cbqhcB7
Forken des Projekt Templates in die Gruppe des Teams ( nur LI)
https://ibb.co/SwKt2WZ
Forken des Projekt Templates in die Gruppe des Teams ( nur LI)
https://ibb.co/SwKt2WZ
Workflow im Detail: GitLab Projektansicht
Projekt URL klonen
https://ibb.co/wBFFhsH
Best Practices
- Strikte Verwendung von Regeln für Clean Code ( Linter nutzen!)
- Häufige lokale Commits : Nach jeder sinnvollen Änderung
- Commit Nachrichten ausreichend kurz, aber aussagekräftig
- Sicherung der Feature Branches ins zentrale Repo in regelmäßigen Abständen (nicht gemeint ist hier merge mit master
- Lokales Repository ( master ) mit pull bzw. fetch+merge aus zentralem Repository aktualisieren
- Push ins zentrale Repository nur, wenn lokales Projekt inkonsistentem Zustand ist, nach Fertigstellung eines Features
- Alten Programmcode nicht auskommentieren, sondern gleich löschen => ständiges Refactoring
Flight rules
Git bietet unumstritten große Vorteile bei der verteilten Arbeit, frustriert Anfänger aber häufig durch die mächtige API.
- Flight rules für Git : https://github.com/k88hudson/git flight rules
- Typische Antworten auf Probleme wie: Ich habe unter dem falschen Namen und der falschen Email Adresse comitted
Literatur / Quellen
Auswahl (nur zum Nachgucken auf die Schnelle nicht zum Lernen)
git
-git Book als aktuelle engl. Version: https:// git scm.com/book/en/v2 bzw. gerade im Übersetzungsprozess: https:// git scm.com/book/de/v2
- git Der einfache Einstieg
http: //rogerdudler.github.io/git guide/index.de.html - Interaktives git Tutorial ( Zeitdauer ca. 15min
https: //try.github.io/levels/1/challenges/1 - Das Git Buch , Download unter
http: //gitbu.ch - git cheat sheet
https: //www.atlassian.com/git/tutorials/atlassian git cheatsheet
git Workflows:
- zentralisierter Workflow
https: //www.atlassian.com/git/tutorials/comparing workflows#centralized workflow - Workflow mit Verzweigungen (
https: //www.atlassian.com/git/tutorials/comparing workflows#feature branch workflow
GitLab
Clonen eines GitLab Projektes
https://ibb.co/qsF5FNV
Geforktes
Projekt
clonen
