Fragen zu GitHub und LaTeX (Windows 7)

[enrico]

edit: Zur Klarstellung, es geht hier um die Software GitHub, die Git implementiert, nicht um Git selber.

Hallo,

habe gerade mal fix GitHub nach der erstbesten nett aussehenden Anleitung im Netz für die Nutzung mit LaTeX eingerichtet. Ich fand die Anleitung als Git-Neuling sehr gut, daher habe ich sie gewählt.

Ich habe noch weitere Fragen. Was ich bisher gemacht habe: Ich habe per Drag & Drop meinen Aufgabenstellungsordner "Aufgabenstellung" hinzugefügt. Ich habe dann auf "commit" geklickt und einen Titel ("Aufgabenstellung Version 2012-04-22") & Kommentar eingegeben. Ich habe noch nichts mit diesem Zweigsymbol "master" darüber gemacht.

• Kann ich nun einfach an der Aufgabenstellung weitertippen und heute Abend erneut committen und dann "Version 29374z" nennen? Sprich, ich habe gerade GitHub geschlossen. Ich kann doch jetzt alles mögliche im Repo machen und heute Abend starte ich einfach wieder GitHub und klicke "commit", korrekt?
• Den Teil "Den Branch wechseln" verstehe ich nicht. Dieser Satz:

  Nun werden alle Dateien in Ihrem Arbeitsverzeichnis auf den Stand gesetzt, den sie hatten, als Sie das letzte Mal mit dem Hauptzweig gearbeitet haben.

  Ich verstehe schon dass wenn man an den master übergeben möchte, muss oben immer "[Zweigsymbol] master" ausgewählt sein. Aber wie genau ist das mit dem Ändern der Dateien gemeint, inwiefern löscht/kopiert/bearbeitet GitHub da Dateien? Und wann genau? Nachdem ich z. B. "commit" im Zweig namens "Betreuer-Vorschlaege" geklickt habe? Wie läuft das ab?

Ich hoffe die Fragen an sich machen Sinn, habe wie gesagt zum ersten Mal mich damit auseinandergesetzt.

 

[gazpel]

Hallo enrico,

zunächsteinmal ist github nicht git, sondern eher eine art Dienst der zusätzlich zu den Funktionen von git weitere bereitstellt bzw. diese komfortabler macht. Um dir zu helfen ohne dich gleich in Informationen zu ertränken wäre es gut wenn du kurz beschreibst, was du erreichen willst.

Gruß,
gazpel

edit: Aber um kurz auf deine Fragen einzugehen:

Ja, du kannst Dateien editieren und später dann commit aufrufen. Eventuell musst du die Dateien dann aber vorher mit add hinzufügen (Es kann sein, dass github das automatisch macht).

Zweige (branches) sind eine Möglichkeit, parallel mehrere Änderungen zu verwalten. Wenn du etwas in master commitest, ist es in 'betreuer-vorschlaege' nicht sichtbar und umgekehrt.

 

[enrico]

Hi gazpel,
ich möchte verschiedene Versionen meiner Studienarbeit abspeichern. Git scheint neben Mercurial und SVN dies zu bewerkstelligen und daher bin ich bei GitHub gelandet, welches auf git-scm.org verlinkt wurde.

Als Alternative zu GitHub hatte ich auch an eine Backup-Software wie Spideroak gedacht, aber mit dem Programm hatte ich nicht so gute Erfahrungen gesammelt. Ich hatte Explorer-Abstütze (ich meine den Prozess explorer.exe) und die GUI ist bisschen umständlich und etwas verbuggt wenn man die detaillierte Ordnerstruktur nutzt.

 

[Silberwoelfin]

Ich bin mir nicht hundertprozent sicher, wie das mit dem grafischen Programm aussieht, das du offensichtlich nutzt, aber bei meiner Kommandozeile muss ich Änderungen einmal commiten mit Kommentar und dann muss ich sie zum Server pushen.

 

[linrunner]

Hi,

wenn Du einfach nur aufeinanderfolgende Arbeitsstände mit Git sichern/archivieren möchtest, dann brauchst Du keinen weiteren Branch, sondern arbeitest immer mit dem "master" und machst einfach immer nur Commits deines Dokuments (ist das eine Datei oder mehrere). Deine eigene Versionsnummierung kannst Du entweder im Commit-Kommentar mit einbauen oder Du arbeitest mit sog. Tags.

Vielleicht hilft dir ein Git-Tutorial weiter, z.B. http://sixrevisions.com/resources/git-tutorials-beginners/ oder http://rogerdudler.github.io/git-guide/index.de.html

Allerdings wird dort meist die Kommandozeilenversion gezeigt und außerdem auf Remote-Repositories herumgeritten. Ich vermute, dass das Tool von Github den Push auf deren Server implizit erledigt.

Wenn Fragen sind einfach Fragen und vielleicht einen Screenshot beifügen, ich benutze nur die Kommandozeile.

 

[gazpel]

Hi,

ganz wichtig: ein git repository ist kein backup! Es ist eine gute Idee deine Studienarbeit in git zu versionieren, zusätzlich solltest du das gesamte Verzeichnis aber regelmäßig sichern (z.B. auf ein NAS zu Hause oder auf einen cloud dienstleister wie wuala. Zusätzlich noch alles auf einen USB-Stick).

Wie in der von dir verlinken Anleitung beschrieben würde ich keinen Gebrauch davon machen, das auf github zu veröffentlichen, da ist es nämlich im wahrsten Sinne des Wortes öffentlich.

Die github Anwendung kenne ich nicht, prinzipiell wird diese aber auch einfach git Befehle verwenden. D.h. dein Workflow sieht wie folgt aus:

Du hast ein Verzeichnis in dem alle Dateien drin sind die deine Studienarbeit braucht.
In diesem Verzeichnis legst du das git repository an (Alternativ leg das repository in einem leeren Verzeichnis an und kopier dann alle Dateien da rein)
Nach dem Anlegen des repositories fügst du alle notwendigen (wenn du dir nicht sicher bist einfach alle) Dateien zum repository hinzu und machst einen initialen commit. Das ist deine erste Version.

Jedes mal wenn du einen gewissen Stand erreicht hast, machst du wieder einen commit, in dessen Kommentar beschreibst du den Stand, oder was sich seit dem letzten commit geändert hat.

In der github Anwendung kannst du dann vermutlich in einer historienansicht alle commits sehen, miteinander vergleichen und wiederherstellen.

Soweit sehr linear. Ich würde am Anfang erstmal dabei bleiben bis du dich daran gewöhnt hast. Insbesondere würde ich auch kleinere Änderungen commiten, nicht 1x täglich oder 1x stündlich, sondern wirklich jedesmal wenn etwas passiert ist. Grafik hinzugefügt -> commit. Absatz fertig -> commit. Fußnote hinzugefügt -> commit.

Wobei 'Absatz fertig' kein guter commit Kommentar wäre. Besser den Inhalt beschreiben ala 'Kapitel 1.2.1 Absatz 3: Beschreibung über gute commit Kommentare hinzugefügt'

Wenn du mehrere Varianten deiner Arbeit pflegen möchtest kannst du dich noch mit Zweigen (stichworte branch/merge) auseinandersetzen.

Ein kleines 'gotcha' bei der Versionierung ist, dass alles was in einer Version commitet wurde im repository immer erhalten bleibt. D.h. wenn du ein 1GB Bild commitest und danach dieses Bild wieder löscht, bleibt es im repository trotzdem erhalten, selbst wenn du erneut commitest oder an gleicher stelle ein 1KB Bild anlegst.
Also wunder dich nicht, wenn das Verzeichnis nie mehr weniger Platz belegt, auch wenn du Dateien löscht.

 

[gazpel]

Hi,
Ich vermute, dass das Tool von Github den Push auf deren Server implizit erledigt.

Man kann wohl beim Start die Accounterstellung/Eingabe umgehen und rein lokal arbeiten.

 

[enrico]

Hallo gazpel,
zunächst einmal vielen Dank für deine ausführliche Antwort. Das ist alles sehr hilfreich.

Wegen den Punkten Backup und GitHub-Veröffentlichung wusste ich schon Bescheid, danke. Habe das mit dem Backup nur genannt weil Spideroak gleichzeitig auch Versionen der gespeicherten ("synchronisierten") Dateien angibt, wobei die aber bisschen versteckt sind. Wie gesagt, die Navigation ist etwas zeitraubend in dem Programm.

Die Methodik, die du beschrieben hast, ist auch so in der GitHub-Anwendung zu bewerkstelligen, glücklicherweise vollkommen via GUI. Seitdem ich versucht habe via cygwin den Minion Pro in Tex Live zu installieren und dabei mir meine Installation irgendwie verbaselt hatte, versuche ich vorerst ohne irgendwie emulierte/virtuelle Linux-Konsolen auf Windows auszukommen.

Insbesondere würde ich auch kleinere Änderungen commiten, nicht 1x täglich oder 1x stündlich, sondern wirklich jedesmal wenn etwas passiert ist. Grafik hinzugefügt -> commit. Absatz fertig -> commit. Fußnote hinzugefügt -> commit.

Wobei 'Absatz fertig' kein guter commit Kommentar wäre. Besser den Inhalt beschreiben ala 'Kapitel 1.2.1 Absatz 3: Beschreibung über gute commit Kommentare hinzugefügt'

Öh... echt? So häufig? Könntest du dafür bitte eine Rationale nennen? Ich hätte jetzt von mir aus gesagt, eher pro Hälfte eines Unterabschnitts, so pi mal Daumen. Habe aber da noch nicht die letzte Weisheit gefunden muss ich sagen.

Ein kleines 'gotcha' bei der Versionierung ist, dass alles was in einer Version commitet wurde im repository immer erhalten bleibt. D.h. wenn du ein 1GB Bild commitest und danach dieses Bild wieder löscht, bleibt es im repository trotzdem erhalten, selbst wenn du erneut commitest oder an gleicher stelle ein 1KB Bild anlegst.
Also wunder dich nicht, wenn das Verzeichnis nie mehr weniger Platz belegt, auch wenn du Dateien löscht.

Wie geht das denn? Total Bahnhof hier. Wird mit Git eine inkrementelle Änderung gespeichert oder immer einen vollen Abzug gemacht? Denn dann würde ich das mit dem Abzweigen (Branch erstellen) auch besser verstehen, das Git(Hub) da selber im Hintergrund Dateien austauscht, ändert... und so weiter.

Hi,

wenn Du einfach nur aufeinanderfolgende Arbeitsstände mit Git sichern/archivieren möchtest, dann brauchst Du keinen weiteren Branch, sondern arbeitest immer mit dem "master" und machst einfach immer nur Commits deines Dokuments (ist das eine Datei oder mehrere). Deine eigene Versionsnummierung kannst Du entweder im Commit-Kommentar mit einbauen oder Du arbeitest mit sog. Tags.

Danke, gut zu wissen, genau so hatte ich es erhofft.

Vielleicht hilft dir ein Git-Tutorial weiter, z.B. http://sixrevisions.com/resources/git-tutorials-beginners/ oder http://rogerdudler.github.io/git-guide/index.de.html

Ja, die Tools sind alle Kommandozeilen-basiert. Hm... noch bin ich froh mit GitHub, es sieht halbwegs ordentlich aus.

Mal eine Frage in den Raum: Nutzt hier wer Git-Gui auch genau mit einem lokalen Repo ohne Veröffentlichung?

 

[gazpel]

Öh... echt? So häufig? Könntest du dafür bitte eine Rationale nennen? Ich hätte jetzt von mir aus gesagt, eher pro Hälfte eines Unterabschnitts, so pi mal Daumen. Habe aber da noch nicht die letzte Weisheit gefunden muss ich sagen.

Letztendlich wirst du mit der Zeit selbst einen Rythmus finden, der für dich funktioniert. Ein commit ist die kleinste Einheit, die du mit git Bordmitteln gegebenenfalls auch einzeln entfernen kannst. Je granularer du das machst desto mehr Möglichkeiten hast du. Es macht keinen Sinn, nach jedem Buchstaben oder jedem Wort zu commiten, aber wenn du z.B. einen wichtigen Satz umformulierst, kann das schon für einen Satz sinnvoll sein. Je mehr Änderungen du in einen commit packst, desto schwieriger wird es in der Historie einzelne Änderungen wiederzufinden oder die Änderungen werden erst garnicht historisiert (du formulierst etwas 2x neu und commitest nicht dazwischen).

Wie geht das denn? Total Bahnhof hier. Wird mit Git eine inkrementelle Änderung gespeichert oder immer einen vollen Abzug gemacht?

In deinem Verzeichnis gibt es ein Unterverzeichnis '.git'. Darin speichert git alle Informationen über die commits, branches etc.. Das wird dir unter Windows eventuell nicht angezeigt, ist aber da. Und da du mit jedem commit neue Informationen (auch das eine Datei gelöscht wurde ist eine Information) hinzufügst, wächst es. Du hast Recht damit, dass git in der Regel nur Änderungen verfolgt, aber grade bei Bildern und anderen Binärdateien ist das nicht so leicht.
Das stellt für dich aber auch kein hinderniss dar, ich wollte nur darauf hinweisen weil es nicht unbedingt intuitiv ist (aber logisch sobald man einmal drüber nachdenkt)

 

[Konrad[030]]

Vielleicht ist ja SparkleShare eine Alternative.

Funktioniert wie Dropbox und im Hintergrund wird es mit git versioniert und kann dementsprechend auch auf GitHub oder anderen Remote Git Repositories gehostet werden.

 

[enrico]

Danke für die weiteren Erläuterungen, gazpel.

Konrad, danke, aber nach weiteren Überlegungen habe ich mich gegen einen Backup via Software entschieden. Dafür habe ich zu wenig "schreckliche" Erlebnisse mit meiner Technik allgemein in meiner gesamten Nutzungszeit gehabt. Meine Laptops fallen mir nicht runter (ok, außer einmal, mein erstes), meine PCs fallen nicht um, alle sonstige Technik .... und so weiter. Ein USB-Stick und Extra-Ordnder wird da reichen müssen.

Hatte übrigens auch mal zwischenzeitlich Git-Gui ausprobiert und... naja, wurde nur verwirrt. Das Programm scheint man nciht mal vollständig von der Platte zu bekommen, bei einer Neuinstallation war noch immer alles in Deutsch. Bleibe daher bei GitHub.

 

[enrico]

Inzwischen bin ich zum mehr oder weniger fertigen 1. Kapitel gekommen. Ich habe parallel zum Ausarbeiten des Kapitels fleißig commitet. Ich habe bisher nur im master Zweig gearbeitet.

Ich habe nun einige Fragen:

1. Wieviele commits macht ihr ungefähr pro Tag, falls an diesem besagten Tag in LaTeX ein Dokument bearbeitet wird?
2. Nach welcher Regel erstellt ihr ein Commit?
3. Was ist der Nutzen für dich persönlich beim Nutzen von git & Schreiben in LaTeX?

Hintergedanke:
Das git repo zu managen hat bisher einen zusätzlichen Verwaltungsaufwand von mir verlangt, bei dem ich langfristig gesehen noch nicht den Nutzen sehe. Ich schreibe ja nicht wie in der Programmierung einen Absatz, der später nicht funktioniert und Fehler beim Kompilieren erzeugt. Ich kann mir im Moment nicht die Situatin vorstellen, in der ich dazu komme diese Versionierung mit GitHub wirklich ausnutzen zu können und dann einen Vorteil zu haben. Denn ich brüte mal über meine Gedanken nach, springe zwischen PDF-Datei und LaTeX hin und her und zack zack, editiere etwas hier und da im Code und ... dann wieder committen wirkt da einfach wie ein Mehraufwand.

Summa summarum: Ich habe momentan nichts gegen GitHub an sich, nur merke ich den Mehrwert nicht. Ich muss mich vom "Gedanken des roten Fadens beim Arbeiten im Dokument" lösen um zu commiten. Das stört leider.

 

[vorlaeufig]

1. Wieviele commits macht ihr ungefähr pro Tag, falls an diesem besagten Tag in LaTeX ein Dokument bearbeitet wird?
2. Nach welcher Regel erstellt ihr ein Commit?
3. Was ist der Nutzen für dich persönlich beim Nutzen von git & Schreiben in LaTeX?

Meine Versionierungs-Erfahrung mit Text-Dokumenten ist zwar schon einige Zeit her, und mit Git habe ich nur wenig praktische Erfahrung, dafür aber reichlich mit Subversion (und CVS - ganz alte Schule ) und Programmcode. Ich fange mal mit Frage 3 an, weil die Antwort darauf die Grundlage für die anderen Fragen gibt, und versuche das aus Deiner Perspektive zu betrachten. Du schreibst alleine an Deiner Arbeit, Du schreibst auf einem Rechner, und Du schreibst einen (nehme ich an) solitären Text, der wenig von externen Gegebenheiten abhängt (im Unterschied z.B. zu technischer Dokumentation o.ä., die von Entwicklungsständen eines Gerätes oder Programms etc. abhängt). Damit fallen schonmal drei Hauptzwecke von Versionierung weg: Synchronisation zwischen mehreren Leuten, Synchronisation zwischen mehreren lokalen Repos, und Versionierung im Wortsinne (also Festhalten definierter Versionen), sowohl in der zeitlichen als auch der "horizontalen" (d.h. verschiedene Entwicklungszweige) Dimension. Was bleibt? Ich sehe v.a. noch die Funktion als Backup (auch wenn gazpel richtig anmerkt, daß Versionierung kein Backup ist, läßt sie sich doch als solches "mißbrauchen"...) und als Dokumentation der Textentstehung. (An dieser Stelle vielleicht mal die Frage, warum Du Dich gerade für Git entschieden hast - liegen dessen Stärken doch v.a. in der verteilten Bearbeitung und der Netzwerkorientierung, und es erscheint mir für Deinen Zweck im Vergleich zu SVN doch deutlich overfeatured.)
Jetzt komme ich auch schon zur zweiten Frage, nach den "Regeln" für ein Commit. Ich gehe dabei aus von der Sicherungsfunktion und sehe da ein Commit als aufgebohrtes Zwischenspeichern - also immer dann, wenn Du es stark bereuen würdest, die Änderungen zu verlieren, sowie vor Arbeitspausen und nach abgrenzbaren Arbeitseinheiten - Beispiele hat gazpel ja schon benannt, wobei ich finde, daß mir ein Absatz oder eine Fußnote schon recht häufig erscheint (hängt aber auch davon ab, welcher Art der Text ist und wie lang Du für den Absatz oder die Fußnote gebraucht hast). Ich hatte (und würde wieder) auch normales Zwischenspeichern benutzt und nur bei Arbeitseinheiten, die sinnvoll und aussagekräftig beschrieben werden konnten, committet. Der Gedanke dabei ist: was möchte ich in der Historie evtl. sehen, und da interessiert es mich kaum als solches, daß ich irgendwann im fortlaufenden Schreibprozeß den dritten Absatz im Kapitel 2.3.1 geschrieben habe. Wann (und warum) ich evtl. später einen dritten Absatz eingefügt bzw. ergänzt habe, wäre hingegen unter bestimmten Umständen interessant zu wissen. Womit wir bei der Dokumentationsfunktion wären. Die Kommentare also nicht nur zur Beschreibung des "Was" nutzen, sondern auch des "Warum", z.B. nicht "Abbildungen formatiert", sondern "Abbildungen aus ästhetischen Gründen auf 80% Textbreite skaliert"; oder "Quellenangaben formatiert", sondern "Quellenangaben an Institutsrichtlinie angepaßt"; nicht "Kapitel x.y umformuliert", sondern "Vorschläge des Betreuers (1. ...,2. ...,3. ...) in Kapitel x.y eingearbeitet".
Mit der Zeit spielt sich das ein, und Du wirst einen Kompromiß finden, der Deinen persönlichen Bedarf an Sicherheit, Dokumentation und ungestörtem Arbeitsfluß erfüllt.

So, genug Text, *COMMIT*