Einführung git Flashcards

1
Q

Vermeidbare Probleme bei der Arbeit mit Daten, Dokumenten, Programmcode, Belegarbeiten:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)

A
  • Letzte Version gelöscht
  • In welcher Datei befindet sich der letzte Arbeitsstand
  • welche Änderungen wurden vorgenommen
  • Kontrolle einer älteren Version nicht möglich
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Probleme im Team:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)

A
  • Welche Version in einer lokalen Kopie passt zu der anderen Version einer anderen einer lokalen Kopie
  • Änderungen überschreiben
  • Änderungsprotokoll
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Motivation:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)

A

-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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Ansatz:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Standardverhalten:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)

A

-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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Lösungsmöglichkeit 1: Sperren
Versionsverwaltung
WIESO, WESHALB, WARUM?

A
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Lösungsmöglichkeit 2: Kopieren Ändern Mischen:
(Versionsverwaltung
WIESO, WESHALB, WARUM?)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

git (Allgemeiner Überblick (1/4))

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

git (Allgemeiner Überblick (2/4))

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

git (Allgemeiner Überblick (3/4))

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

git (Allgemeiner Überblick (4/4))

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

git (Nomenklatur) auch deutsch :D für welche Wörter sind wichtig!

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

git (Werkzeuge)

A

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Prinzip Git

Erste Schritte und Kommandos (lokal 1)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Erste Schritte und Kommandos (lokal 2)

A

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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Erste Schritte und Kommandos (lokal 3)

A

https://ibb.co/L90RzVs

17
Q

Erste Schritte und Kommandos (lokal 4)

A

https://ibb.co/Mg0qByN

-Lokales leeres git Repository anlegen 1/2)
aktuelles Verzeichnis wird zu leerem git Repository
z.B. Laufwerk

D: Ablage s#####

18
Q

Erste Schritte und Kommandos (lokal 5)

A

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

19
Q

Erste Schritte und Kommandos (lokal 6)

A

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

20
Q

Erste Schritte und Kommandos (lokal 7)

A

https: //ibb.co/hZDWJ7n
- Commit Meldungsfenster mit Hash Wert der Version

-Historie anzeigen TortoiseGit > Show log

21
Q

Erste Schritte und Kommandos (lokal 8)

A

https://ibb.co/BrNwxDp

-Änderungen anzeigen
TortoiseGit > Diff

-aktuell bearbeitete Version
umschalten switchen
TortoiseGit > Show log >
Checkout to this

22
Q

Arbeiten im Team

vereinfacht

A

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

23
Q

Arbeiten im Team

Prinzip:

A

https://ibb.co/x1Btvnr
Prinzip
Arbeiten mehrere Entwickler gleichzeitig an einem Projekt,
entwickeln sie parallel => das Projekt verzweigt

24
Q

Arbeiten im Team

Remote git Repository in lokales Repository kopieren:

A

https://ibb.co/xMFznPq
Remote git Repository in lokales Repository kopieren
im Zielverzeichnis: git clone

25
Q

Arbeiten im Team

Neue/aktuelle Version vom remote Repository holen

A

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..

26
Q

Arbeiten im Team

Hochladen der eigenen aktuellen Version ins remote Repository und

A

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

27
Q

Arbeiten im Team

Konflikte

A

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.

28
Q

Branches: Basiskommandos

A

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.

29
Q

Branches: Basiskommandos Tortoise

A

https://ibb.co/3YjCYSg

Branch anlegen und hineinwechseln

30
Q

Branches: Basiskommandos Tortoise

A

https://ibb.co/FVcvVhp

Änderungen vom lokalen Branch ( hier : Aufgabe9_ST_Collect ) sollen in den lokalen master branch zurückgeführt werden merge

31
Q

Workflow

im Team Übersicht

A

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

32
Q

Workflow im Team

Übersicht

A

https://ibb.co/zZrR5Sw

33
Q

Workflow im

Detail: GitLab Erster Start (1) und Start (2) und Start (3) und Start (4)

A

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

34
Q

Workflow im Detail: GitLab Projektansicht

A

Projekt URL klonen

https://ibb.co/wBFFhsH

35
Q

Best Practices

A
  • 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
36
Q

Flight rules

A

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
37
Q

Literatur / Quellen

Auswahl (nur zum Nachgucken auf die Schnelle nicht zum Lernen)

A

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
38
Q

GitLab

Clonen eines GitLab Projektes

A

https://ibb.co/qsF5FNV

Geforktes
Projekt
clonen