Informatik im Daltonplan-Unterricht GIT

aus ZUM-Wiki, dem Wiki für Lehr- und Lerninhalte auf ZUM.de
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

nicht nur für die Schule interessant

Ein Gymnasium hat ein Dashboard entwickelt, um den (Distanz)Unterricht zu organisieren. Es ist gekoppelt mit Jitsi und einer NextCloud. Man kann Aufgaben stellen, Materialien und einen Abgabeordner zur Verfügung stellen und Feedback in schriftlicher und Audio Form geben, alles gekoppelt mit einem Stundenplan. Alles ist sehr clever gemacht. Klickt ein Schüler einen Link zu einer Jitsi Konferenz in einer Stunde, ist er direkt authentifiziert und mit Namen dort angemeldet. Dokumentation und ein Video mit Erklärung unter Specht-schule GitHub


Buch-Empfehlung

Buch zum Git


Versionskontrolle

  • VCS
  • CVCS
  • DVCS


Repository

Frontend backend mobile-Entwicklung

Patch(Flickwerk)=KorrekturAuslieferung einer Datei

Patch-Set werden kombiniert um eine Datei wieder zusammen zu setzen

VersionsKontrolle:

in der Geschichte der DateiVeränderung reisen

VCS VersionsKontrolle lokal.

Cvcs zentral. Zentraler Zugriff. Alles auf einem Server. Single Point-of-failer = alle Daten können auf einen Schlag verloren gehen.

Dvcs Distributed = alle Daten werden auf alle Client (Rechner) gespiegelt

Geschichte von GT

Rechnungsentwickler wollten nicht-lineare (mehrere Nutzer entwickeln gleichzeitig ihre Teile) und schnelle Entwicklung haben.

Github Prinzipien (Gir cheat sheet)

Nicht Delta (Unterschiede von Version 1 zu v2 zu v3 und danach zusammen gesetzt). Stattdessen Verweis auf die alte unveränderter Version (SNAP Shot). Ist immer fertig.

Jede Operation ist lokal verfügbar, muss nicht auf Server zugreifen.

Integrität: Prüfsumme um korrupte Dateien zu erkennen

Gut fügt Daten hinzu (Falls sie zufällig gelöscht worden sein sollten)

Drei Zustände von git

  • modified (nur lokal aber nicht im respository)
  • staged (für aktuelle Version vorgemerkt)
  • commited (Übertragen und gespeichert)

Respository: hier alles fertig Ins Working Directory kopieren Dann ins Staged area (Stage fixed) dann wieder ins respository

Paket-Installation

Bei Ubuntu z.B. apt-get: apt-get install git Git config - - global user.emial „you@epl.org“. - - user.name „myname „

erste Schritte

Git init = Repository Initiieren
Gut add = Dateien vormerken zum hinzufügen (Aus dem WorkingDirectory zu der  staging Arena)
Git commit -m  ´meine Nachricht zu dieser Aktion‘ Dateien ins Repository hochladen (aus der staging Arena zum repository)
Git rm Dateiname Datei löschen
Git rm --cached myheim.jpg Datei aus der Versionsverwaltung zu entfernen, aber auf der Festplatte zu behalten

Status einer Datei:

Untracked = noch nicht im Repository drin
Staged
Modified
Unmodified ( im repo)
Git remote add repo „http://...“
Hier auch Git remote alias oder remove um Zusammenarbeit zu benutze 
Git clone = aus der online DB eine Kopie auf unseren pc ziehen
Git push-> ins online repo schreiben 
Git fetch = aus dem online repo rausholen
Git merge online repo mit meinen Änderungen verbinden
Git pull = fetch und merge in einem
Git rm datei.txt löschen
Git rm —cached datei.txt aus git löschen, aber lokal lassen
Git reset HEAD - - datei.txt aus dem staging Bereich entfernen

Staging

  • speichern der Datei (blob)
  • Prüfsumme berechnen
  • Prüfsumme zu der Stagging Area hinzufügen

Beim commiten Werden zu allem Verzeichnissen Prüfsummen erstellt mit einer Baumobjekt mit Zeigern auf die blobs. Hinzu kommen Meta Daten (User/E-Mail-Adresse) und Zeiger zu den Vorgänger Daten (Parents).

Daraus wird ein Commit – Objekt erstellt (bestehend aus Meta– Daten, Zeiger auf Tree und Nachrichten)

Baumobjekt bekommt ebenfalls eine Prüfsumme

Beispiel

Tree(643g)
Blob 8ut54 liste1.txt
Blob 4a921 liste2.txt


Blob(45g6)

# Überschrift dazu
Inhalte der Datei 
Mein Text dazu


Commit (87f9)

Tree 643g
Author car
Commuter cat
Meine Nachricht


Branch

ist Abzweigung von der Hauptlinie (ohne diese zu verändern)

Branch (ist ein Zeiger) zeigt auf den Commit

Master-Branch zeigt immer auf den aktuellen Commit

Bei git commit bewegt sich der Master automatisch weiter

HEAD = Zeiger auf den aktuellen Master

$  git branch <brachname>  erzeugt den Branch auf den aktuellen Commit, bewegt ihn aber nicht
$ git checkout -b <branchname> lässt HEAD auf den  <branchname>


Merge

$ git merge <der-weitere-branch> wird zu dem aktuellen commit hinzugefügt 
 Master wird automatisch auf den letzten commit verschoben


History

git commit -m ‚was wurde neu gemacht‘