Ich bin Autor, kein Programmierer. Ich lerne gerade zum ersten Mal etwas über die Versionskontrolle und wie sie funktioniert, und ich frage mich, wie die Versionskontrolle meinen Arbeitsablauf optimieren könnte.
In einer früheren Frage habe ich gefragt, welches Versionskontrollsystem verwendet werden soll, und mich für Git entschieden.
Jahrelang habe ich meine eigene zusammengeschusterte Version der Versionskontrolle verwendet. Meine Ordner sind übersät mit Dateien wie „resume-2012-06-01.doc“, „resume-2012-06-15.doc“, „letter.txt“, „letter-old.txt“, „letter-v2.txt“, „story-notes.txt“, „story“. -notes-with-character-sketches.txt story_draft1.txt, story_draft2.txt, story_draft2-shorter.txt usw.
Jetzt, da ich die Versionskontrolle verwende, muss ich wohl nicht all diese umbenannten Versionen einer Datei manuell erstellen. Was soll ich stattdessen tun? Wie soll ich jetzt, da ich die Versionskontrolle verwende, meine Entwürfe und Umschreibungen benennen? Wie behalte ich den Überblick über Entwürfe und Überarbeitungen?
Welche Philosophie und Praktiken sollte ein Autor zum Kommentieren verwenden, wenn er einen Git-Commit von Umschreibungen und Überarbeitungen durchführt, um alles im Auge zu behalten und Dinge später leicht zu finden?
Es gibt zwei Konzepte in Git, die helfen können: Branches und Tags .
Stichworte. Stellen Sie sich ein Tag als Namen für eine bestimmte Revision vor. Jedes Mal, wenn Sie sich an eine Version erinnern möchten, erstellen Sie ein Tag dafür. Wenn Sie beispielsweise einen Entwurf fertiggestellt haben, können Sie ihn folgendermaßen taggen:
git tag first_draft
Wann Sie Tags verwenden sollten. Tags eignen sich gut zum Markieren von Versionen, an die Sie sich später erinnern möchten. Ich verwende sie, um das Ende jedes Entwurfs zu markieren.
Geäst. Stellen Sie sich einen Zweig als eine Reihe von Änderungen vor. Der Standard-Zweig heißt master. Das ist ein guter Zweig, den Sie für Ihre erste Recherche und Ihren ersten Entwurf verwenden können. Sofern Sie keinen neuen Zweig erstellen, aktualisiert jede Änderung, die Sie vornehmen, den masterZweig.
Wann man Verzweigungen verwendet. Wann immer Sie mit einer neuen Reihe von Bearbeitungen beginnen möchten, haben Sie die Wahl. Sie können entweder mit dem aktuellen Zweig fortfahren oder einen neuen Zweig erstellen.
Einige mögliche Verwendungen für Zweige:
Entwürfe. Sie können jeden Entwurf beginnen, indem Sie einen Zweig dafür erstellen. (Ich neige dazu, dies nicht zu tun, aber es könnte Ihren Bedürfnissen entsprechen.)
Experimente. Angenommen, Sie möchten mit dem Umschreiben einiger Szenen experimentieren, um von der Ich- in die Dritte-Person-Perspektive zu wechseln oder den POV-Charakter zu ändern. Sie können einen Zweig erstellen und dort Ihre Experimente durchführen. Wenn Ihnen der neue POV später gefällt, können Sie weiter an Ihrem experimentellen Zweig schreiben. Wenn Ihnen die POV-Änderungen doch nicht gefallen, können Sie zu dem Zweig zurückkehren, auf dem Sie zuvor waren.
Einreichungen. Bevor ich etwas einschicke, erstelle ich oft einen neuen Zweig, füge mein Anschreiben hinzu, nehme kleinere Manuskriptänderungen speziell für diesen Empfänger vor (z. B. Macken von mss-Formaten) und füge eine Textdatei mit Notizen über das Einreichen hinzu. Wenn ich eine Antwort erhalte, kann ich den Zweig überprüfen und meine Notizen aktualisieren.
Ich neige dazu, Zweige eher für Experimente und Einreichungen als für Entwürfe zu verwenden. Wenn ich einen Entwurf fertig habe, tagge ich ihn und fahre dann mit dem zweiten Entwurf auf dem masterZweig fort.
Filialen erstellen. Um einen neuen Zweig zu erstellen, verwenden Sie den git branchBefehl wie folgt:
git branch charles_pov
Wenn Sie eine neue Verzweigung erstellen, beginnt die neue Verzweigung mit demselben Inhalt wie die Verzweigung, in der Sie sich befanden. Wenn Sie sich in der masterVerzweigung befinden und eine charles_povVerzweigung erstellen, charles_povbeginnt die Verzweigung mit dem aktuellen Inhalt der masterVerzweigung.
Beachten Sie, dass das Erstellen eines neuen Zweigs nicht zum neuen Zweig wechselt. Um zu einem Zweig zu wechseln, siehe unten.
Filialen wechseln.
Sie können Zweigstellen jederzeit wechseln, indem Sie eine Zweigstelle "auschecken". So wechseln Sie zu Ihrer neuen charles_povFiliale:
git checkout charles_pov
Wenn Sie Änderungen festschreiben, aktualisiert git den Zweig, in dem Sie sich befinden, und lässt die anderen Zweige unverändert. Wenn Sie also zum charles_povZweig wechseln, aktualisieren Ihre Änderungen den charles_povZweig, und der masterZweig bleibt unverändert.
Erstellen einer Verzweigung und Wechseln zu ihr in einem Befehl. Sie können einen neuen Zweig erstellen und mit einem einzigen Befehl zu ihm wechseln, wie folgt:
git checkout -b charles_pov
Anzeigen von Tags und Zweigen. Mit diesen Befehlen können Sie eine Liste aller Tags und Zweige anzeigen:
git tag
git branch
Ein Tag auschecken (UND EINE WARNUNG). Denken Sie daran, dass ein Tag ein Name für eine bestimmte Version ist. Wenn Sie jeden Entwurf markiert haben, können Sie sich einen alten Entwurf wie folgt ansehen:
git checkout twelfth_draft
Ja, Sie checken ein Tag genauso aus wie einen Zweig.
ABER BEACHTEN SIE , dass Sie sich beim Auschecken eines Tags nicht mehr in einem Zweig befinden. Alle Änderungen, die Sie vornehmen, enden an einem schwebenden, nebulösen Ort, den ich nicht prägnant erklären kann. Git warnt Sie davor.
Der aktuelle Zweig. Verwenden Sie diesen Befehl, um zu sehen, in welchem Zweig Sie sich gerade befinden:
git branch
Git zeigt alle Branches an und markiert den aktuellen Branch (derjenige, der aktualisiert wird, wenn Sie Änderungen vornehmen) mit einem Sternchen.
Um nur ein wenig den Advokaten des Teufels zu spielen, ich denke, es kann definitiv argumentiert werden, kein Software-Versionskontrolltool schriftlich zu verwenden.
Als Autor, der auch in der Softwareentwicklungsbranche arbeitet, habe ich einige Lieblingstheorien dazu, obwohl ich selbst immer noch experimentiere.
1967 prägte ein Computerprogrammierer namens Melvin Conway das, was als "Conway's Law" bekannt geworden ist: "Organisationen, die Systeme entwerfen ... sind gezwungen, Designs zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind."
Dies bedeutet im Grunde, dass eine Software sehr wahrscheinlich (oder sogar zwangsläufig) der Organisation ähneln wird, die sie erstellt hat. Dies liegt daran, dass Software (wie das Schreiben) „weich“ ist und ein Teil der Funktionalität auf viele Arten erreicht werden kann, sodass ein Softwareentwickler von Natur aus mehr durch die Organisation, für die er arbeitet, eingeschränkt ist als durch die Tools, die er verwendet.
Ich habe eine folgerichtige Lieblingstheorie, dass die beim Schreiben verwendeten Werkzeuge unweigerlich die Art der mit ihnen erstellten Arbeit beeinflussen. Du könntest sagen "na und?" Schließlich sind für die Softwareentwicklung konzipierte Versionskontrollsysteme wunderbare und leistungsstarke Werkzeuge, die es manchmal Hunderten von Ingenieuren und Entwicklern ermöglichen, effektiv zusammenzuarbeiten. Ich würde sagen "genau".
Gutes Schreiben hat ein anderes Endziel als gutes Programmieren. (Ich spreche nicht von technischer Redaktion oder Dokumentation, sondern von Prosa). Das Schreiben von Prosa soll eine intensive persönliche Erfahrung zwischen dem Autor und dem Leser schaffen (der normalerweise versucht, sich zu entspannen und mit einem zeitaufwändigen, aber unterhaltsamen Buch aus einer chaotischen, schnelllebigen Welt zu entkommen). Das Produkt der Arbeit des Schriftstellers ist direktdem Leser (oder Endbenutzer) ausgesetzt werden, im Gegensatz zu einer Software, bei der 99 % der Zeit, in der der Code, den ein Entwickler schreibt, unter einer Abstraktionsschicht einer visuell basierten UI (Benutzeroberfläche) verborgen ist. Bei fast jeder Softwareanwendung ist die Freude des Benutzers an der Anwendung völlig unabhängig von der Qualität des Codes in der Geschäftsschicht. Wenn der Code ausreichend gut geschrieben ist, damit die Anwendung überhaupt funktioniert, ist die Erfahrung für den Benutzer gleich, ob es sich um unverständlichen Spaghetti-Code oder schön minimalistische, gut kommentierte Kunst handelt. Das ist bei einem Autor absolut nicht der Fall.
Der Sinn von etwas wie Git besteht also darin, Code zu sammeln und aufzubewahren und die Rückverfolgbarkeit und Änderungskontrolle zu ermöglichen. Es sammelt im Laufe der Zeit Änderungen im Code von mehreren Entwicklern oder einem einzelnen Entwickler und ermöglicht es Ihnen, Dinge wie die Bereitstellung eines Änderungssatzes zu tun, zu erkennen, dass Sie die gesamte Anwendung vermasselt haben, und Ihre Änderung rückgängig zu machen oder sogar einen Teil davon zu integrieren. Es geht darum, den funktionalen Zustand der Anwendung zu erhalten, nicht die zusammenhängende „Stimme“ des Codes. Code hat normalerweise keine zusammenhängende "Stimme", insbesondere in Fällen, in denen ein großes Team an einem Projekt zusammengearbeitet hat. Wenn Sie also die Versionskontrolle verwenden, um einen Roman zu schreiben, werden Sie vom Tool ermutigt, mehrere Versionen des Romans gleichzeitig zu pflegen, Teile zwischen den Versionen hin und her zu ändern, Behalten Sie jedes einzelne Wort, das Sie irgendwo geschrieben haben, und können Sie es wieder einfügen, und erstellen Sie ein sich ständig erweiterndes lebendiges Dokument ohne Endzustand. Eine Softwareanwendung wird kontinuierlich umgeschrieben, bis sie aufgegeben wird. Jedes Mal, wenn ein Fehlerticket, ein Update für etwas, von dem die Anwendung abhängt, ein Update für einen Browser, der die Anwendung verwendet, oder eine neue Bereitstellung von Funktionen vorliegt, werden irgendwo Änderungen am Code vorgenommen. Die einzigen statischen und unveränderlichen Software-Apps sind tote Abandonware. Ein Roman ist etwas ganz anderes. Sie müssen den Roman bearbeiten und ihn in eine endgültige, unveränderliche Form bringen, die sich nicht ändert. Auch wenn es möglich ist, einen sich ständig ändernden Roman auf ein Gerät wie einen Kindle zu liefern, wollen die Leser das nicht. Sie tun Sie möchten nicht in einem Buch, das sie bereits lesen, zurückgehen und in Kapitel 2 neue Änderungen finden und versuchen, sie in ihr Verständnis der Geschichte zu integrieren. Leser möchten, dass ein Buch fertig und statisch ist, bevor sie anfangen, es zu lesen.
Wenn Ihr Tool Sie dazu ermutigt, ausführlich zu sein, potenziell unendliche Versionen einer Geschichte zu behalten und nie einen fertigen Zustand erreichen zu müssen, denke ich, dass viele Autoren, insbesondere weniger erfahrene, die ohnehin dazu neigen, zu ausführlich zu sein, dies tun würden eher gigantische "Schlammballen"-Romane schreiben, die letztlich unlesbar sind. Ich sage das als jemand, dessen erster Roman dieser Beschreibung entspricht.
Schriftsteller hatten schon immer eine gewisse Verbindung zu den Werkzeugen, die sie verwenden, weshalb die Leute Romanautoren immer noch mit klappernden Schreibmaschinen assoziieren. Die Werkzeuge beschränkenuns und zwingen uns, unseren Endzustand im Auge zu behalten, bevor wir Worte zu Papier bringen. Hemingway schrieb im Zeitalter der Schreibmaschinen mit der Hand, und viele modernere Autoren benutzten im Zeitalter der Computer Schreibmaschinen. Es geht nicht darum, ein Luddit zu sein, es geht um die psychologische Wirkung, wenn man weiß, dass das, was man aufs Papier bringt, irgendwie unveränderlich ist und nicht einfach rückgängig gemacht werden kann. Es zwingt uns, prägnant zu sein, Worte sorgfältig zu wählen und mehr in unserem Gehirn und weniger im Werkzeug zu schreiben. Die Versionskontrolle fördert mehr Schreiben im Tool und weniger in unserem Gehirn. Ich denke, wir haben im Zeitalter der Textverarbeitung bereits eine Lawine von schlechtem Schreiben gesehen, und die Versionskontrolle könnte ein Schritt zu weit auf dem falschen Weg sein, wenn es um Prosa geht.
Um die Frage zu beantworten: Vielleicht nicht.(?)
Ich weiß nicht, ob die ausgefeilte Funktionalität von git so nützlich wäre, es sei denn, Sie arbeiten vielleicht mit einem anderen Autor zusammen. Git bietet jedoch ein paar Dinge, die für den Autor möglicherweise interessant oder nützlich sind.
Das erste und etwas Triviale ist, dass es die Buchhaltungsversionen Ihres Textes sauber für Sie erledigt, ohne Sie damit zu belästigen, welche Namen welche sind, oder sich zu fragen, ob Sie die richtige Version bearbeiten. Sie könnten also einfach auf Ihrem Master-Branch bleiben, Ihre Änderungen täglich committen, sich aber immer mit Dateien wie Chapter01.md befassen. Seine Versionierung ohne Unordnung.
Faszinierender ist vielleicht, dass Sie beim Commit aufgefordert werden, einen Kommentar hinzuzufügen, der das Commit beschreibt. Programmierer verwenden es, um die Art der vorgenommenen Änderung anzuzeigen (z. B. „Einmaligen Indexierungsfehler beheben“), aber für den Autor relevanter ist möglicherweise eine Reflexion über das Geschriebene, eine Art Tagebuch des Autors, das Sie während der Arbeit führen eine lange.
Monika Cellio