Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Game Engines

Verwenden der Versionskontrolle mit Unity3D

by
Read Time:12 minsLanguages:

German (Deutsch) translation by Władysław Łucyszyn (you can also view the original English article)

Dieser Artikel soll eine endgültige Anleitung zur ordnungsgemäßen Versionskontrolle Ihrer Unity-Projekte sein!

Die Versionskontrolle ist eines der wichtigsten Werkzeuge im Arsenal eines Entwicklers. Sie können Änderungen einfach rückgängig machen, wenn Sie versehentlich etwas kaputt machen, ältere und neuere Versionen Ihres Codes vergleichen, um festzustellen, was sich unterscheidet, und Teams können an demselben Code arbeiten, ohne versehentlich die Arbeit des anderen zu überschreiben. Bis vor kurzem konnten nur Unity Pro-Projekte ordnungsgemäß versioniert werden. Seit Unity 3.5 ist es jetzt jedoch auch möglich, Projekte in der kostenlosen Version von Unity zu steuern.


Was ist Versionskontrolle?

Ein Versionskontrollsystem (VCS) verfolgt Änderungen, die Sie an Dateien im Ordner vorgenommen haben, der auch als "Arbeitskopie" bezeichnet wird. Diese Änderungen werden neben dem Ordner in einer Datenbank gespeichert, die als "Repository" bezeichnet wird. Jedes Mal, wenn Sie etwas in Ihrer Arbeitskopie ändern, müssen Sie diese Änderungen in das Repository übernehmen. Das VCS vergleicht dann das, was sich bereits im Repository befindet, mit den eingehenden Änderungen und speichert nur die Unterschiede. Dies hält das Repository so klein wie möglich.

Committing to Local RepositoryCommitting to Local RepositoryCommitting to Local Repository

Für dieses Projekt verwenden wir Mercurial, ein verteiltes VCS. Im Gegensatz zu zentralisierten VCS-Systemen wie Subversion (SVN), die normalerweise auf einem auf einem Server gespeicherten Remote-Repository basieren, kann ein verteiltes VCS lokale Repositorys, manchmal auch als "lokale Zweige" bezeichnet, direkt auf Ihrem Computer hosten. Dies bedeutet, dass Sie Änderungen vornehmen, sie in Ihrer lokalen Niederlassung festschreiben, testen und sogar verwerfen können, wenn etwas kaputt geht, ohne dass Sie Ihre Teammitglieder Ihren Änderungen unterziehen müssen, bis Sie wissen, dass sie perfekt sind. Sobald Sie sicher sind, können Sie diese Änderungen in ein Remote-Repository "pushen", damit Ihr Team sie in die eigenen lokalen Niederlassungen "ziehen" kann.

Pushing and Pulling from a Remote RepositoryPushing and Pulling from a Remote RepositoryPushing and Pulling from a Remote Repository

Vorbereiten eines Unity-Projekts für die Versionskontrolle

Für ein Unity-Projekt sind bestimmte Metainformationen erforderlich, um sich zu merken, welche Komponenten und Verbindungen für die verschiedenen Assets festgelegt sind. Traditionell wurden diese Metainformationen als eine Reihe von Binärdateien im Bibliotheksordner eines Unity-Projekts gespeichert. Dieser "binäre Blob" kann jedoch nicht ordnungsgemäß zusammengeführt werden, sodass Änderungen, die von zwei Personen vorgenommen wurden, übereinander stampfen und dazu führen können, dass im Editor Probleme auftreten, selbst wenn sie unterschiedliche Assets bearbeiten.

Die Lösung hierfür besteht darin, Metadateien in den Projekteinstellungen zu aktivieren.

  • Klicken Sie auf Bearbeiten > Projekteinstellungen > Editor
  • Ändern Sie unter der Überschrift Versionskontrolle den Modus in Metadateien
  • Klicken Sie auf Datei > Speichern
Editor settings

Dadurch erstellt Unity neben jedem Asset im Ordner "Project Assets" Metadateien. Wenn nun ein Asset im Editor geändert wird, werden nur das Asset und die zugehörige Metadatei anstelle des gesamten Bibliotheksordners Änderungen gemeldet.

Meta files

Mercurial installieren

Sowohl Windows als auch OSX verfügen über Mercurial-Installationsprogramme. Besuchen Sie die Mercurial-Website und klicken Sie auf den großen Download-Button. Die Site erkennt automatisch, welches Betriebssystem Sie verwenden, und lädt das entsprechende Installationsprogramm herunter.

Download button

Entpacken Sie das Installationsprogramm und führen Sie es aus. Klicken Sie sich durch alle Schritte und es sollte sich selbst installieren, ohne dass ein Eingriff erforderlich ist.

InstallersInstallersInstallers

Öffnen Sie eine Befehlszeile, um sicherzustellen, dass Mercurial korrekt installiert ist. Drücken Sie unter Windows Start und geben Sie cmd in das Suchfeld ein. Öffnen Sie unter OSX Spotlight und suchen Sie nach dem Terminal.

Command lineCommand lineCommand line

Geben Sie in der Befehlszeile Folgendes ein:

Es sollte eine kurze Liste mit Informationen angezeigt werden, einschließlich der von Ihnen verwendeten Mercurial-Version sowie eine Liste allgemeiner Befehle. Geben Sie Folgendes ein, um die vollständige Liste der Befehle zu erhalten:

Um Hilfe zu einem bestimmten Befehl zu erhalten, geben Sie einfach den Namen des Befehls nach der Hilfe ein:

HINWEIS: Mercurial-Befehle beginnen immer mit hg, dem Element für Quecksilber im Periodensystem. Zum Glück wurde diese clevere Benennung verwendet, weil sie einfach zu tippen ist.


Repository initialisieren

Als erstes müssen wir unserem Projektordner ein Repository geben.

Geben Sie in der Befehlszeile Folgendes ein:

Das ist es. Unser Ordner hat jetzt ein Repository und ist bereit für die Versionskontrolle. Wenn Sie versteckte Dateien aktiviert haben, werden Sie feststellen, dass im Projektordner ein .hg-Ordner erstellt wurde. Hier befindet sich das Repository. Wenn Sie aus irgendeinem Grund die Versionskontrolle entfernen möchten, löschen Sie einfach den Ordner .hg. Ihre Arbeitskopie der Dateien bleibt unversehrt.

hg folderhg folderhg folder

Status überprüfen

Nachdem unser Projektordner über ein Repository verfügt, überprüfen wir den Status des Repositorys, um festzustellen, was sich geändert hat. Mercurial akzeptiert verkürzte Befehlsnamen, sodass eine der folgenden Funktionen funktioniert:

Ein Statusbericht sollte eine Liste von Dateien enthalten, neben denen jeweils ein Buchstabe steht. In diesem Fall werden alle Dateien mit Fragezeichen versehen. Das Fragezeichen zeigt an, dass die Datei im Repository noch nicht versioniert ist.

? Eine Datei, die sich in der Arbeitskopie befindet, aber nicht vom Repository verfolgt wird.
! Eine Datei, die vom Repository verfolgt wird, aber in der Arbeitskopie fehlt.
A Eine Datei, die seit dem letzten Commit zum Repository hinzugefügt wurde.
M Eine Datei, die seit dem letzten Festschreiben geändert wurde.
R Eine Datei, die beim nächsten Commit aus dem Repository entfernt werden soll.

Hinzufügen von Dateien zum Repository

Wir müssen Dateien explizit zu unserem Repository hinzufügen, damit Mercurial weiß, dass sie versioniert werden sollen.

Einzelne Dateien können hinzugefügt werden:

Ganze Ordner können hinzugefügt werden:

Fügen wir jede einzelne nicht versionierte Datei (mit einem ? Fragezeichen im Statusbericht) auf einen Schlag hinzu, indem Sie überhaupt keinen Dateinamen angeben:

Führen Sie eine Statusprüfung durch.

Alle hinzugefügten Dateien sollten jetzt mit einem Buchstaben A versehen sein, der angibt, dass sie dem Repository hinzugefügt wurden und jetzt von Mercurial verfolgt werden.


Änderungen übernehmen

Nachdem wir Mercurial mitgeteilt haben, welche Dateien versioniert werden sollen, müssen wir sie in das Repository übertragen. Jedes Commit ist wie ein als Revision bezeichneter Snapshot, der die Unterschiede zwischen den vorherigen und den aktuellen Revisionen verfolgt.

Jedes Commit besteht aus zwei Teilen: einer Nachricht und Ihrem Benutzernamen. In der Nachricht können Sie beschreiben, was Sie getan haben, aber halten Sie es kurz und bündig. Der Benutzername ist nur eine Kennung, mit der alle anderen Benutzer des Repositorys wissen, wer bestimmte Änderungen vorgenommen hat. Der Benutzername wird mit dem Flag -u und die Nachricht mit dem Flag -m gesetzt:

Um sicherzustellen, dass das Festschreiben erfolgreich war, müssen wir das Protokoll überprüfen:

Um doppelt sicher zu sein, überprüfen Sie den Status, um sicherzustellen, dass keine Änderungen mehr vorhanden sind.

Ein leerer Statusbericht bedeutet, dass alles ordnungsgemäß festgeschrieben wurde.

HINWEIS: Es wird empfohlen, dass Sie häufig ein Commit durchführen. Jedes Commit sollte so "atomar" wie möglich sein. Das heißt, es sollte leicht durch einen einfachen Satz wie "erhöhte Spielersprunghöhe" beschrieben werden können. Wenn Sie in Ihren Festschreibungsnachrichten "und" oder Kommas verwenden müssen, ist es wahrscheinlich an der Zeit, zwei separate Festschreibungen vorzunehmen. Der Grund dafür ist, dass es einfach ist, bestimmte Änderungen, die Sie bei Problemen vorgenommen haben, rückgängig zu machen.


Fehler beheben

Es gibt zwei wichtige Möglichkeiten, um Fehler zu beheben: einen Rollback oder einen Revert. Ein Rollback macht den zuletzt eingegebenen Befehl rückgängig. Dies ist ideal, um Rechtschreibfehler in Ihren Festschreibungsnachrichten zu beheben oder eifrig hinzuzufügen.

Führen Sie eine Statusprüfung durch, um sicherzustellen, dass alles korrekt zurückgesetzt wurde.

Ein Zurücksetzen ist leistungsfähiger und ermöglicht es Ihnen, durch mehrere Revisionen in die Vergangenheit zu reisen, falls Sie von mehreren vorgenommenen Änderungen zurücktreten müssen. Um herauszufinden, auf welche Revision Sie zurückgreifen möchten, müssen Sie zunächst das Protokoll überprüfen:

Log

Entweder die Nummer oder der Hash können verwendet werden, um beim Zurücksetzen auf eine bestimmte Revision zu verweisen. Die Nummer ist spezifisch für Ihr Repository, da der Zweig einer anderen Person möglicherweise mehr Änderungen aufweist, sodass ihre Nummern unterschiedlich wären. Der Hash ist universell, d.h. jeder kann mithilfe dieser Hash-Zeichenfolge zu einer bestimmten Revision in einem gemeinsam genutzten Repository zurückkehren.

Um zu einer bestimmten Revision zurückzukehren, müssen Sie die Revisionsnummer mit dem Flag -r angeben. Wir müssen Mercurial auch anweisen, mit dem Flag -a "alle zurückzusetzen". Schließlich müssen wir Mercurial mitteilen, dass keine Sicherungsdateien mit dem Flag --no-backup erstellt werden sollen.

Führen Sie eine Statusprüfung durch, um sicherzustellen, dass alles korrekt wiederhergestellt wurde.

HINWEIS: Wenn Sie das Flag --no-backup weglassen, erstellt Mercurial Sicherungsdateien für alle Dateien, die von der Wiederherstellungsprozedur betroffen sind. Diese Sicherungsdateien haben alle die Erweiterung .orig. Stellen Sie sicher, dass Sie keine .orig-Dateien hinzufügen.


Unerwünschte Dateien ignorieren

Nachdem wir unseren Fehler behoben haben, stellen wir sicher, dass er nicht erneut auftritt. Wir möchten die Ordner "Library" und "Temp" dauerhaft ignorieren, damit sie nicht versehentlich hinzugefügt werden, wenn wir das nächste Mal mit dem Befehl "add" zufrieden sind.

Mercurial verwendet eine spezielle Datei namens .hgignore, um die Namen von Dateien und Ordnern zu speichern, die Sie dauerhaft ignorieren möchten. Diese Datei befindet sich direkt in Ihrem Projektordner und ist wie alles andere versioniert. Dies stellt sicher, dass jeder, der das Repo verwendet, es nicht versehentlich mit unerwünschten Dateien verschmutzen kann.

Verwenden Sie Ihren bevorzugten Texteditor, um Folgendes einzugeben:

Dies teilt Mercurial mit, welche Shell-Syntax (als "Glob" -Syntax bezeichnet) verwendet werden soll, um die Ordner Library und Temp zu ignorieren, mehrere von MonoDevelop erstellte temporäre Dateien zu ignorieren und .orig-Dateien zu ignorieren, falls wir sie versehentlich erstellen, wenn Zurücksetzen.

Speichern Sie die Datei im Stammverzeichnis Ihres Projektordners als .hgignore (beachten Sie den Punkt am Anfang). Führen Sie dann eine weitere Statusprüfung durch:

Die .hgignore-Datei sollte jetzt im Statusbericht aufgeführt sein, der Bibliotheksordner, der Temp-Ordner und andere ignorierte Dateien jedoch nicht. So können wir den Befehl add sicher verwenden, ohne genaue Dateinamen verwenden zu müssen, und dann die Ergebnisse festschreiben.

Überprüfen Sie das Protokoll, um sicherzustellen, dass das Festschreiben erfolgreich war.

HINWEIS: Weitere Informationen zu hgignore-Dateien finden Sie hier.


Übertragen von Änderungen in ein Remote-Repository

Wenn Sie Ihr Repository für andere Entwickler freigeben möchten, ist es am einfachsten, ein Remote-Repository auf einem Server zu erstellen und Ihre Änderungen darauf zu übertragen.

Als erstes müssen Sie einen Mercurial-Host finden. Es gibt mehrere, darunter BitBucket und Kiln; Beide haben kostenlose Konten für kleine Teams. In unserem Fall verwenden wir BitBucket, aber beide Dienste funktionieren im Wesentlichen gleich. Wenn Sie sich für ein Konto bei einem der beiden Dienste angemeldet haben, müssen Sie über die Weboberfläche ein neues Repository erstellen.

HostsHostsHosts

Suchen Sie nach dem Erstellen nach dem "Klonpfad". Es sollte ungefähr so aussehen:

hg clone https://bitbucket.org/username/reponame

Normalerweise wird dieser Befehl verwendet, um eine lokale Kopie des Repositorys zu erstellen. Wir haben jedoch bereits ein lokales Repository und möchten stattdessen Änderungen an das Remote-Repository senden. Dazu können wir die URL-Adresse am Ende der Klonzeichenfolge als Ziel für den Push-Befehl verwenden.

Mercurial vergleicht das lokale Repository mit dem Remote-Repository, um festzustellen, wie sie sich unterscheiden. Es wird angezeigt, dass unser lokales Repository neuere Änderungen aufweist, die im Remote-Repository fehlen, und diese an das Remote-Repository senden.

Zunächst werden Sie jedoch zur Eingabe eines Benutzernamens und eines Kennworts aufgefordert. Diese sollten dem Benutzernamen/der E-Mail-Adresse und dem Passwort entsprechen, mit denen Sie sich beim Host-Dienst angemeldet haben.

Mercurial sollte melden, dass alle Änderungen erfolgreich übertragen wurden. Dies bedeutet, dass jeder, der von Ihrem Repository abhängig ist, jetzt daraus "pull" kann, um Ihre Änderungen zu erhalten. Zuerst müssen sie das Repository klonen, um eine lokale Kopie zu erstellen.

Und ziehen Sie dann alle Änderungen, die Sie oder andere Personen im Laufe der Zeit vornehmen:

Sie müssen dann ein "update" durchführen, um sicherzustellen, dass Ihre Arbeitskopie aktualisiert wird:

Um Zeit zu sparen, können Sie das Pull-and-Update auf einmal mit dem Flag -u ausführen:

HINWEIS: Mercurial fordert Sie auf, wenn eine Binärdatei aktualisiert oder zusammengeführt wird. Wenn Sie nicht sicher sind, dass Sie Änderungen an lokalen Binärdateien vorgenommen haben, wählen Sie immer die Option "(O)other" anstelle der Option "(L)ocal".


Einstellungen, um das Leben einfacher zu machen

Es gibt mehrere mühsame Aspekte, wenn dieselben Befehle immer wieder ausgegeben werden, z. B. dass Sie beim Festschreiben daran denken müssen, einen Benutzernamen anzugeben, bei jedem Drücken ein Kennwort eingeben müssen usw. Viele dieser Einstellungen können in einer sogenannten hgrc-Datei gespeichert werden. Verwenden Sie zum Erstellen einer hgrc-Datei Ihren bevorzugten Texteditor und geben Sie Folgendes ein:

Dies teilt Mercurial mit, welcher Pfad standardmäßig für Push- und Pull-Befehle verwendet werden soll. Stellen Sie sicher, dass Sie diese gefälschte Adresse durch die tatsächliche Adresse Ihres Remote-Repositorys ersetzen. Geben Sie als Nächstes Folgendes ein:

Dies teilt Mercurial mit, welchen Benutzernamen beim Festschreiben standardmäßig verwendet werden soll. Ersetzen Sie dies erneut durch Ihre korrekten Anmeldeinformationen und stellen Sie sicher, dass die E-Mail-Adresse mit der übereinstimmt, mit der Sie sich angemeldet haben. Geben Sie abschließend Folgendes ein:

Dadurch wird Mercurial mitgeteilt, welche Anmeldeinformationen beim Pushing in ein sicheres Remote-Repository verwendet werden sollen, damit Sie nicht bei jedem Push oder Pull einen Benutzernamen und ein Kennwort eingeben müssen. Stellen Sie sicher, dass Sie das Präfix durch den kürzestmöglichen Teil der Adresse Ihres Hosts ersetzen und das http://-Protokoll auch nicht in das Präfix aufnehmen. Ersetzen Sie als Nächstes den Benutzernamen und das Passwort durch das, mit dem Sie sich bei Ihrem Host angemeldet haben. Das Schema teilt Mercurial mit, mit welchen Protokollen versucht werden soll, eine Verbindung herzustellen.

Speichern Sie die Datei schließlich als hgrc (ohne Punkt oder Erweiterung am Ende) im Ordner .hg in Ihrem Repository. Sie sollten von nun an keine manuellen Benutzernamen, Kennwörter oder Pfade mehr eingeben müssen, wenn Sie Befehle ausgeben.


Abschluss

Die Versionskontrolle mag den Uneingeweihten ein wenig entmutigend erscheinen, aber der Aufwand lohnt sich. Sie können beruhigt wissen, dass Sie ein defektes Projekt jederzeit an einen Punkt zurücksetzen können, an dem es zuvor funktioniert hat. Ebenso bedeutet die Verwendung von Remote-Repositorys, dass Code nicht nur für Teammitglieder freigegeben werden kann, sondern dass die Wiederherstellung Ihres Projekts nach einem katastrophalen Ereignis (z. B. einem Festplattenausfall) einfach ist.

Hg InitHg InitHg Init

Um mehr über verteilte Versionskontrolle und Mercurial zu erfahren, empfehle ich dringend, Hg Init zu besuchen. Es enthält eine Reihe von Artikeln, in denen Versionskontrollpraktiken und Mercurial-Funktionen ausführlich erläutert werden. Es ist kurz, sehr informativ, leicht zu lesen, leicht zu verstehen und sogar ein bisschen lustig.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.