Neuigkeiten

Frohes neues Jahr, euch allen!

Entdecke die dunkle Seite in dir und mach mit bei der Schurken Challenge!

Thema: Schreibprojekt verwalten mit Git  (Gelesen 369 mal)

BlueScullyZ

  • Lieutenant
  • ***
  • Beiträge: 580
Schreibprojekt verwalten mit Git
« am: November 24, 2016, 03:33:47 Nachmittag »
Weil ich gerade so in Tutorial-Stimmung bin :P

Ne Anleitung, wie man mit Git seine Geschichte mittels Versionskontrolle verwalten kann.

Vorweg: Was heißt das? Ihr kennt das, wenn ihr schreibt. Bis zu einem bestimmten Punkt, könnt ihr eure Änderungen zurücknehmen. Speichert ihr euer Dokument und schließt es, ist diese Änderungshistorie weg und zu vorherigen Speicherständen könnt ihr in der Regel auch nicht zurück, es sei denn, man hat sie noch einmal seperat abgespeichert - oder in einer Versionskontrollsoftware.
Git (oder Bazar/SVN u. co) speichert diese verschiedenen Versionen eurer Datei. Ähnlich wie bei Wikieinträgen, bei denen man ja auch vorherige Stände auswählen kann. Und damit ist es möglich, zu älteren Ständen zurückzukehren oder diese mit der aktuellen Version zu vergleichen. Kann manchmal praktisch sein.

Noch ne Warnung. Git ist ursprünglich für Entwickler entwickelt worden, um Code zu versionieren. Entsprechend ... technisch angehaucht ist das Tool. Hat keine wirklich "fancy"-Oberfläche und wirklich gut lässt es sich eigentlich nur mit der (Git) Bash bedienen. Aber ich geb mir Mühe, es so einfach wie möglich zu beschreiben. Bin fest davon überzeugt, wer will, kriegt das mit Leichtigkeit hin.


Repository ... äh, Moment!
Bevor wir das anlegen: Das Repository ist das, was Git zu eurem Projekt speichert. Änderungen, Konfigurationen, Benutzer, Berechtigungen, Hooks ... Ich erklär alles, was ihr braucht, keine Sorge. Was ihr aber verstehen solltet, dass Git alles in 3 verschiedenen Zuständen vorhält.
Eine Datei besteht in einem Repository aus folgenden Bestandteilen: Die Datei selbst, wie sie in eurem Ordner liegt, die ihr anklicken und bearbeiten könnt. Teil zwei sind alle gespeicherten Änderungen, also alle verfügbaren Zustände, der Datei. Teil Drei ist der Unterschied zwischen dem letzten gespeichertem Zustand und der Datei, wie sie in eurem Verzeichnis liegt.

Beispiel:
Inhalt der Datei, wie sie in eurem Verzeichnis liegt: Arbeitsverzeichnis (Tree)
Paul mag Blattspinat.

Und Käse.


Änderungen seit dem letzten Speichern im Repository: Stage
--- Paul mag keinen Spinat.
+++ Paul mag Blattspinat.
+++
+++ Und Käse.


Zustände, die im Repository vorhanden sind: Index
Version xxxx
--- Paula mag keinen Spinat.
+++ Paul mag keinen Spinat.

Version xxxy
--- Paula mag keinne Spinat.
+++ Paula mag keinen Spinat.

Version xxyy (Da wurden zwei ganze Zeile gelöscht)
--- Ganz wichtig:
---
--- Paula mag Spinta
+++ Paula mag keinne Spinat.
...


Und, wenn man will, könnte man jetzt zu Version xxyy zurückkehren. In diesem Fall gibt es keinen Grund, aber die Möglichkeit ist da.


Git installieren
Git SCM

Für Windowser: Datei laden, speichern ...
  • ... Datei ausführen.
  • Eine Information, was du jetzt tust. Durchlesen und auf Weiter klicken.
  • Lizenzbedingungen. GNU ... Darfste nicht verkaufen, darfst es frei nutzen, ohne kommerziellen Hintergrund. Weiter.
  • Komponenten! Wir kommen zum interessanten Teil der Angelegenheit. Für die Mutigen oder IT-affinen unter auch: "GIT Bash Here". Für die Zögerlichen ... erst recht. Wissen ist Macht :P Weiter.
  • Integration der Git Bash. Der Standard genügt, wer Git auch über die CMD bedienen will, nehmt Nr. 2. Nr. 3 empfehle ich nur Leuten, die wissen, was der PATH ist.
  • Zeilenenden ... Warum man das auswählen muss: Unter Linux/Unix (LF) wird ein Zeilenumbruch anders kodiert als unter Windows (CRLF). WENN ihr einen Windows-PC habt, nehmt Nr. 1. Aber andernfalls würdet ihr diese Instalationsroutine ja auch nicht machen ... Also: Weiter.
Fertig.

Für Linux: Terminal aufmachen und folgendes eingeben
# Ubuntu/Debian und Co
apt-get install git

# Fedora & RedHat
yum install git

# SuSE
zypper in git

Komplettvorgang in Kurz (Git Bash)
git config --global user.name "Euer Name"
git config --global user.email eure@email.adresse
cd /Verzeichnis/deines/Projekts
git init
# Sobald Dateien im Verzeichnis liegen, die getrackt werden sollen
git add *
git commit -m "Hinweis zum Speicherpunkt, z. B. Kapitel 14 überarbeitet, Planet heißt jetzt Plutus"

#Status abrufen
git status
# Zum Ansehen der History
git log
# Zum Zurückkehren zu einem Speicherpunkt
git checkout <Commit-ID> /Pfad/zur/Datei/die/wiederhergestellt werden soll

Und jetzt das ganze in ausführlich:

Repository anlegen
Das funktioniert sowohl in einem leeren Ordner, als in einem bestehenden, mit Dateien gefülltem Ordner.

For the nerds (and the brave ones)
  • Startet unter Windows die "Git Bash", unter Linux geht zurück in eurer Terminal
  • Wechselt in das Verzeichnis, in dem ihr das Repo anlegen wollt ...
# Kleiner Bash-Crashkurs: cd steht für change directory - wechsel den Ordner
# Und gleich noch ein kleiner Profi-Tipp: Wenn ihr nicht weiter wisst, drückt einfach 2x die Tag Taste ;-)

cd /Users/Benutzer/Documents/Pfad/wo/euer/Projekt/liegen/soll/wo/auch/immer/das/ist
  • Wun-der-bar! Jetzt konfigurieren wir Git zum ersten Mal.
git config --global user.name "Euer Name"
git config --global user.email eure@email.adresse
  • Und wieder ein Schritt weiter. Jetzt initialisiert ihr das Git-Repository.
git init
  • Herzlichen Glückwunsch! Das wars.

Gra-Fische müssen sich gedulden, füg ich noch ein ...


Änderungen speichern (auf "git": einchecken)
Wenn ihr in dem Ordner schon Dokumente liegen habt, habt ihr gleich was, womit ihr testen könnt. Bisher ist das Repository nur da, ihr müsst ihm jetzt noch sagen, dass er die Dateien auch überwachen soll. Bei Änderungen an den Dateien, wenn ihr also einen Speicherpunkt (Commit) erstellen wollt, geht ihr genauso vor.
  • Änderungen anzeigen lassen
git status
  • Änderungen für den Speicherpunkt vorsehen (macht man, damit man auch Dateien von dem Speicherpunkt ausnehmen kann, weil man die unter einen seperaten Punkt packen will)
git add ...
# Um ALLE Dateien dem Speicherpunkt hinzuzufügen
git add *

# Um nur .doc-Dateien dem Speicherpunkt hinzuzufügen
git add *.doc

# Um nur eine bestimmte Datei dem Speicherpunkt hinzuzufügen
git add Kapitel\ 14.odt

# Um ausschließlich die Kapitel 3, 9 und 13 hinzuzufügen
git add Kapitel\ 3.odt Kapitel\ 9.odt Kapitel\ 13.odt
# oder (hrhr, RegEx yeah!)
git add Kapitel\ (3|9|13).odt
  • Status nochmal prüfen
git status
# Da sollte jetzt alles, was ihr dazugefügt habt, grün angezeigt werden.
  • Speicherpunkt erstellen (Stand commiten)
git commit -m "Hinweis zum Speicherpunkt, wie z.B. Szene mit Heinz und Emma auf der Wiese wegen P18+ gestrichen."
  • Fertig.

Änderungen zurücknehmen / zu einem früheren Stand wechseln (auschecken)
Schon etwas höhere Magie, ich schreib es auch hier rein, weil ich es immer wieder suchen muss, wenn ich es mal brauche :P

  • Bevor ihr loslegt, solltet ihr den aktuellen Stand noch einmal commiten (speichern)
  • Speicherpunkte auflisten
# Alle Änderungen auflisten
git log

# Nur einige Änderungen auflisten
git log -<Anzahl der Änderungen, die man zurückschauen möchte>

# Nur Änderungen zu einer Datei anzeigen
git log /Pfad/zur/Datei
# bzw. um auch Namensänderungen zu verfolgen
git log --folow /Pfad/zur/Datei
  • Die lange, beängstigende Nummer kopieren, die bei dem Commit (Speicherpunkt) steht, den ihr meint, wiederhaben zu wollen
Beispiel: e3463dd7c1ac5fc76194c0cda0bc387869868882
  • Prüfen, ob der Stand der richtige ist
git diff <Lange, beängstigende Nummer> HEAD /Pfad/zur/Datei
# Übersetzung: Git, vergleiche den Stand der Datei /Pfad/zur/Datei von damals (<lange, beängstigende Nummer>) mit dem letzten gespeichertem Zustand (HEAD)
  • Lest euch die Änderungen durch, sie werden automatisch rot/grün dargestellt
  • Verlasst die Vergleichs-Darstellung mit einem Druck auf die Taste Q (für Quit)
  • Falls das die Version ist, zu der ihr zurückgehen wollt, stellt sie jetzt wieder her (sonst, sucht weiter. Belohnt wird, wer eindeutige Commits angelegt hat xD)
git checkout <lange, beängstigende Nummer> /Pfad/zur/Datei
# Beispiel:
# git checkout e3463dd7c1ac5fc76194c0cda0bc387869868882 Kapitel\ 14.html
  • Jetzt kannst du ganz normal im Datei-Explorer/Dateimanager deiner Wahl die Datei öffnen und, e viola, sie sieht aus, wie du sie haben wolltest
  • Falls es doch nicht das war, was du wolltest, kannst du jetzt wieder den letzten commiteten Stand herstellen
git checkout HEAD /Pfad/zur/Datei

    Und bei Zeiten füg ich die grafische Bedienung auch noch ein. Und, wie man sich ein Bare-Repository für mehrere Ablageorte und zur Synchronisation der verschiedenen Arbeitsstationen anlegt ;-)
    « Letzte Änderung: November 25, 2016, 08:35:25 Vormittag von BlueScullyZ »

    BlueScullyZ

    • Lieutenant
    • ***
    • Beiträge: 580
    Antw:Schreibprojekt verwalten mit Git
    « Antwort #1 am: Juni 16, 2017, 10:15:53 Vormittag »
    Die grafische Dokumentation fehlt noch, ich weiß, aber wie man sein Repo über mehrere Orte spiegelt wollte ich nochmal aufschreiben.

    Zugegebenermaßen ist das ein wenig tricky und echter was für Fortgeschrittene Kellerkinder, denn man braucht entweder im eigenen Netzwerk einen freigegebenen Ordner (Windoof-Heimnetzwerk) oder einen Samba-Share oder NFS, auf den alle Geräte, die ihr braucht, zugreifen können. Einen kleinen Heimserver also, ein Netzwerklaufwerk. Wer sich mal dran versuchen will, aber nach dem dritten Satz hier kein Wort mehr versteht, kann mich gerne fragen, ich geb auch gerne Hilfestellung zum Aufbau von Heimnetzwerken :D
    Wenn ihr eure Daten über euer Zuhause hinaus zugänglich machen wollt, geht das einfacher, da hilft euch GitHub (github.org) gerne weiter.

    Zunächst erstellt ihr wie oben gezeigt euer Repository. Und jetzt gehts ans Eingemachte.
    Wenn ihr Zugriff auf euren Heimserver habt (RasPi + Samba z. B.) und einen Linux Desktop, schaltet euch darauf auf und macht die folgenden Schritte direkt von dort aus.
    Aber falls das nicht der Fall ist, führt die Schritte auf eurem PC aus und verschiebt anschließend das erzeugte zweite Repository einfach dorthin, wo es liegen soll.

    Wir brauchen eine Kopie eures Repositories, das ihr oben erstellt habt. Diese Kopie legen wir später dann so ab, dass alle Benutzer drauf zugreifen können und sich den Stand dieser Kopie ziehen können und ihre Änderungen wieder an diese Kopie schicken können. Es ist am einfachsten, mit dieser Kopie zu arbeiten, da niemand Änderungen direkt an der Kopie vornehmen wird und daher ungespeicherte Änderungen keinen Konflikt beim Zusammenfügen mehrer Änderungen hervorrufen können. Diese Kopie, die wir hier anlegen, ist ein Bare-Repository. Ein Repository ohne Arbeitsverzeichnis (Index), das einzig und allein den Verlauf der Änderungen verwaltet.

    Geht aber ganz einfach. Wechselt in ein Verzeichnis, in das ihr euer Bare-Repo ablegen wollt.
    cd /Pfad/zum/Ordner
    Jetzt braucht ihr den Pfad zu eurem Arbeitsrepository, das ihr oben erstellt habt und dann kann es losgehen.
    git clone --bare /Prad/zum/Repository/das/geklont/werden/soll
    Beispiel: git clone --bare /media/user/Volume/Dokumente/StarTrek/AlterNormenSchuldigkeit/BandII

    ## Optional könnt ihr dem Ordner auch einen anderen Namen geben
    ## Zum Beispiel "LilaPonys"
    git clone --bare /Prad/zum/Repository LilaPonys

    Ihr müsstet jetzt im Verzeichnis einen Ordner haben, der so heißt, wie euer anderes Repository oder so, wie ihr ihn genannt habt ("LilaPonys"). Im Ordner enthalten sind allerdings nur die Git-Konfigurationsdateien, keine Dokumente eurer Geschichte. Und das ist gut so!
    Wenn ihr das Repo jetzt auf einen anderen Rechner verschieben wollt, könnt ihr das jetzt tun. Ihr müsst allerdings darauf achten, dass ihr von euren anderen Geräten darauf zugreifen könnt und auch die entsprechenden Rechte besitzt. Wie gesagt, nicht so einfach.

    Jetzt müsst ihr noch eurem alten Repo sagen, dass es Änderungen, die ihr abgespeichert habt, auch später an euer Bare-Repository senden soll. Das Ganze nennt sich "Upstream". Dafür braucht ihr den kompletten Dateipfad zu dem Ort, an dem euer Bare-Repository endgültig, nach dem Verschieben, liegt. Am einfachsten ist es, wenn ihr eine Freigabe habt und das mal im Browser von eurem eigenen Rechner aus ausprobiert, darauf zuzugreifen und dann die Pfadangabe kopiert.
    Wichtig: Wenn ihr das Kommando eingebt, müsst ihr in dem Ordner sein, wo euer ursprüngliches Repository liegt.
    git branch --set-upstream /Pfad/zum/Bare-Repo
    Beispiel mit Freigabe: git branch --set-upstream "/mnt/data/GIT/Alter Normen Schuldigkeit.git"
    Beispiel ohne Freigabe: git branch --set-upstream "git@192.168.5.5:/data/GIT/Alter Normen Schuldigkeit.git"

    Jetzt kennen wir ja schon das Kommando, zum hinzufügen von Änderungen (add) und zum Erzeugen eines Speicherpunkts (commit). Jetzt kommt ein neuer hinzu, bei dem wir die Änderungen in unsere Schattenkopie (Bare-Repository) schicken.
    git pushJa, manchmal ist es einfach einfach. Wohin er es pushen soll, haben wir ihm ja schon gesagt und da wir nicht mit Branches arbeiten, brauchen wir ihm auch die Angabe nicht zu sagen. Im besten Fall hat das geklappt. Im schlimmsten Fall kann er wegen falsch vergebenen Rechten (keine Schreibrechte, keine Leserechte, Benutzer ist nicht authorisiert ...) nicht drauf zugreifen. Wenn ihr es ohne Freigabe gemacht habt und keine SSH-Keys ausgetauscht habt, werdet ihr außerdem wahrscheinlich nach einem Passwort gefragt, sofern der Benutzer eins gesetzt hat.

    Aber gesetzt den Fall, es hat alles funktioniert, könnt ihr nun von einem anderen Gerät aus (Laptop, whatever), auf dem ihr Git auch erst installieren müsst, euch eure eigene Kopie zum Arbeiten ziehen, mit allen Änderungen eurer Arbeit.
    Ihr geht einfach in das Verzeichnis, in dem euer Projekt mal liegen soll und sagt
    git clone /Pfad/zum/Bare-Repository
    Beispiel mit Freigabe (Linux): git clone "/mnt/data/GIT/Alter Normen Schuldigkeit.git"
    #Es wird in der Git-Bash trotzdem mit Pfadnotation wie in Linux gearbeitet, also kein P:\
    Beispiel mit Freigabe (Windows): git clone "/P/data/GIT/Alter Normen Schuldigkeit.git"
    Beispiel ohne Freigabe: git clone "git@192.168.5.5://data/GIT/Alter Normen Schuldigkeit.git"[/code]
    Und tada, nachdem er eine Weile gerödelt hat - meist unter 60 Sekunden - habt ihr einen neuen Ordner.

    Wenn ihr etwas an einer der beiden Kopien ändert, könnt ihr sie wieder an das Bare-Repo schicken und euch die Änderungen auf dem anderen Gerät holen.
    git pull --rebaseUnd dann mit den Änderungen natlos weiterarbeiten - nur nicht vergessen, sie hinterher wieder mit push zu schicken.


    Ich weiß, der Abschnitt ist wirklich seeeeehr technisch, aber falls jemand sich doch mal fragt, wie das denn geht ... :)