Dieser Artikel soll eine definitive Anleitung zur korrekten Versionskontrolle Ihrer Unity-Projekte sein!
Die Versionskontrolle ist eines der wichtigsten Werkzeuge im Arsenal eines Entwicklers. Sie können Änderungen problemlos rückgängig machen, wenn Sie versehentlich etwas kaputt machen, ältere und neuere Versionen des Codes vergleichen, um zu sehen, was anders ist, und Teams können mit demselben Code arbeiten, ohne 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 versionieren.
Ein Versionskontrollsystem (VCS) verfolgt die Änderungen, die Sie an Dateien in einem Ordner vorgenommen haben (auch als "Arbeitskopie" bezeichnet). Diese Änderungen werden zusammen mit 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, 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.
Für dieses Projekt verwenden wir Mercurial, ein verteiltes VCS. Im Gegensatz zu zentralen VCS-Systemen wie Subversion (SVN), die normalerweise auf einem Remote-Repository basieren, das auf einem Server gespeichert ist, kann ein verteiltes VCS lokale Repositorys (manchmal auch als "lokale Zweige" bezeichnet) direkt auf Ihrem Computer hosten. Das heißt, Sie können Änderungen vornehmen, sie an Ihre lokale Niederlassung übergeben, testen und sogar verwerfen, wenn etwas kaputt geht, ohne dass Ihre Teammitglieder Ihren Änderungen unterworfen werden müssen, bis Sie wissen, dass sie perfekt sind. Wenn Sie sich sicher sind, können Sie diese Änderungen in ein Remote-Repository "pushen", damit Ihr Team in ihre eigenen lokalen Zweigstellen "ziehen" kann.
Ein Unity-Projekt erfordert bestimmte Metainformationen, 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är-Blob" kann jedoch nicht ordnungsgemäß zusammengefügt werden, sodass Änderungen, die von zwei Personen vorgenommen werden, sich gegenseitig stampfen und zu Fehlern im Editor führen können, selbst wenn sie andere Assets bearbeiten.
Die Lösung hierfür ist das Aktivieren von Metadateien in den Projekteinstellungen.
Dies führt dazu, dass Unity neben jedem Asset im Projektassetsordner Metadateien erstellt. Wenn ein Asset im Editor geändert wird, werden jetzt nur das Asset und die zugehörige Metadatei Änderungen anstelle des gesamten Bibliotheksordners gemeldet.
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.
Entpacken Sie das Installationsprogramm und führen Sie es aus. Klicken Sie sich durch alle Schritte und es sollte sich installieren, ohne dass ein Eingriff erforderlich ist.
Öffnen Sie eine Befehlszeile, um sicherzustellen, dass Mercurial ordnungsgemäß installiert ist. Drücken Sie unter Windows Start und Typ cmd in das Suchfeld. Öffnen Sie unter OSX Scheinwerfer und suchen nach Terminal.
Geben Sie in der Befehlszeile Folgendes ein:
hg .
Es sollte eine kurze Liste mit Informationen angezeigt werden, einschließlich der von Ihnen verwendeten Version von Mercurial sowie einer Liste gebräuchlicher Befehle. Um die vollständige Liste der Befehle anzuzeigen, geben Sie Folgendes ein:
hg helfen
Um Hilfe zu einem bestimmten Befehl zu erhalten, geben Sie einfach nach der Hilfe den Namen des Befehls ein:
hg helfen klonen
HINWEIS: Merkur-Befehle beginnen immer mit hg, das Element für Quecksilber im Periodensystem. Zum Glück wurde dieses bisschen clevere Benennung verwendet, weil es leicht einzugeben ist.
Als erstes müssen wir unserem Projektordner ein Repository geben.
Geben Sie in der Befehlszeile Folgendes ein:
hg init
Das ist es. Unser Ordner verfügt jetzt über ein Repository und ist zur Versionskontrolle bereit. Wenn Sie versteckte Dateien aktiviert haben, werden Sie eine der folgenden Informationen sehen: .hg Ordner wurde im Projektordner erstellt. Hier befindet sich das Repository. Wenn Sie aus irgendeinem Grund die Versionskontrolle entfernen möchten, löschen Sie einfach die .hg Mappe. Ihre Arbeitskopie der Dateien bleibt davon unberührt.
Nun, da unser Projektordner ein Repository hat, überprüfen wir den Status des Repositorys, um zu sehen, was sich geändert hat. Mercurial akzeptiert verkürzte Befehlsnamen, daher kann Folgendes funktionieren:
hg status hg stat hg st
Ein Statusbericht sollte eine Liste von Dateien mit jeweils einem Buchstaben enthalten. 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 vom Repository nicht verfolgt wird. |
! | Eine Datei, die vom Repository verfolgt wird, aber in der Arbeitskopie fehlt. |
EIN | Eine Datei, die seit dem letzten Commit zum Repository hinzugefügt wurde. |
M | Eine Datei, die seit dem letzten Commit geändert wurde. |
R | Eine Datei, die beim nächsten Commit aus dem Repository entfernt werden soll. |
Wir müssen Dateien explizit zu unserem Repository hinzufügen, damit Mercurial wissen kann, dass sie versioniert werden sollen.
Einzelne Dateien können hinzugefügt werden:
hg add myfile.txt
Ganze Ordner können hinzugefügt werden:
hg add scripts /
Fügen wir nun jede einzelne unversionierte Datei hinzu (mit einem ? Fragezeichen im Statusbericht) auf einen Schlag, indem Sie überhaupt keinen Dateinamen angeben:
hg add
Führen Sie eine Statusprüfung durch.
hg status
Alle hinzugefügten Dateien sollten jetzt einen Buchstaben haben EIN Neben ihnen wird angezeigt, dass sie zum Repository hinzugefügt wurden und nun von Mercurial verfolgt werden.
Nachdem wir Mercurial mitgeteilt haben, welche Dateien wir versioniert werden wollen, müssen wir sie dem Repository übergeben. Jedes Commit ist wie ein Snapshot, der als Revision bezeichnet wird und die Unterschiede zwischen der vorherigen und der aktuellen Revision aufzeichnet.
Bei jedem Commit gibt es zwei Teile, eine Nachricht und Ihren Benutzernamen. In der Nachricht können Sie beschreiben, was Sie getan haben, aber kurz und knapp halten. Der Benutzername ist nur eine Kennung, mit der jeder andere Benutzer, der das Repository verwendet, weiß, wer bestimmte Änderungen vorgenommen hat. Der Benutzername wird mit eingestellt -u Flag und die Nachricht wird mit gesetzt -m Flagge:
hg commit -u ian -m "initial"
Um sicherzustellen, dass das Commit erfolgreich war, müssen wir das Protokoll überprüfen:
hg log
Um sicherzugehen, überprüfen Sie den Status, um sicherzustellen, dass keine Änderungen vorhanden sind.
hg status
Ein leerer Statusbericht bedeutet, dass alles ordnungsgemäß übergeben wurde.
HINWEIS: Es wird empfohlen, dass Sie sich häufig festlegen. Jedes Commit sollte so "atomar" wie möglich sein. Das heißt, es sollte leicht durch eine einfache Phrase wie "erhöhte Spielersprunghöhe" beschrieben werden. Wenn Sie in Ihren Commit-Nachrichten "und" oder Kommas verwenden müssen, ist es wahrscheinlich an der Zeit, zwei separate Commits durchzuführen. Der Grund dafür besteht darin, das Zurücksetzen bestimmter Änderungen, die Sie bei Problemen vorgenommen haben, einfach zu machen.
Es gibt zwei Möglichkeiten, Fehler zu beheben: ein Rollback oder ein Revert. Bei einem Rollback wird der zuletzt eingegebene Befehl rückgängig gemacht. Dies ist ideal, um Rechtschreibfehler in Ihren Commit-Nachrichten oder übermäßiges Hinzufügen von Fehlern zu korrigieren.
hg rollback
Führen Sie eine Statusprüfung durch, um sicherzustellen, dass alles korrekt zurückgesetzt wurde.
hg status
Ein Revert ist leistungsfähiger und ermöglicht es Ihnen, durch mehrere Revisionen in der Zeit zurück zu reisen, falls Sie einige Ihrer vorgenommenen Änderungen rückgängig machen müssen. Um herauszufinden, welche Revision Sie wiederherstellen möchten, müssen Sie zunächst das Protokoll überprüfen:
hg log
Entweder die Nummer oder der Hash kann verwendet werden, um während des Zurücksetzens auf eine bestimmte Revision zu verweisen. Die Nummer ist spezifisch für Ihr Repository, da die Zweigstelle einer anderen Person möglicherweise mehr Änderungen aufweist, so dass sich deren Anzahl unterscheidet. Der Hash ist universell. Dies bedeutet, dass jeder zu einer bestimmten Revision in einem gemeinsam genutzten Repository mithilfe dieser Hash-Zeichenfolge zurückkehren kann.
Um zu einer bestimmten Revision zurückzukehren, müssen Sie die Revisionsnummer mit der angeben -r Flagge. Wir müssen Mercurial auch anweisen, "alle zurückzusetzen", indem Sie die -ein Flagge. Schließlich müssen wir Mercurial mitteilen, dass keine Sicherungsdateien mit der --keine Sicherung Flagge.
hg -r 0 -a - no-backup zurücksetzen
Führen Sie eine Statusprüfung durch, um sicherzustellen, dass alles korrekt zurückgesetzt wurde.
hg status
HINWEIS: Wenn Sie das weglassen --keine Sicherung Wenn Sie dieses Kennzeichen setzen, erstellt Mercurial Sicherungsdateien für alle Dateien, die von der Wiederherstellungsprozedur betroffen sind. Diese Sicherungsdateien haben alle eine .orig Erweiterung. Achten Sie darauf, nicht hinzuzufügen .orig Dateien.
Nun, da wir unseren Fehler rückgängig gemacht haben, stellen wir sicher, dass es nicht wieder passiert. Wir möchten die Library- und Temp-Ordner dauerhaft ignorieren, damit sie nicht versehentlich hinzugefügt werden können, wenn wir das nächste Mal mit dem Befehl add auslösen.
Mercurial verwendet eine spezielle Datei namens .hgignore, um die Namen der Dateien und Ordner zu speichern, die Sie dauerhaft ignorieren möchten. Diese Datei befindet sich direkt in Ihrem Projektordner und ist wie alle anderen Versionen versioniert. Dies gewährleistet, dass jeder, der das Repo verwendet, es nicht versehentlich mit unerwünschten Dateien verschmutzen kann.
Verwenden Sie Ihren bevorzugten Texteditor, um Folgendes einzugeben:
Syntax: glob Library Temp * .pidb * .sln * .userprefs * .csprog * .orig
Dies teilt Mercurial mit, was wir mit Shell-Syntax ("Glob" -Syntax) tun wollen, um die Library- und Temp-Ordner zu ignorieren, mehrere temporäre Dateien zu ignorieren, die von MonoDevelop erstellt werden, und um diese zu ignorieren .orig Dateien nur für den Fall, dass wir sie beim Wiederherstellen versehentlich erstellen.
Speichern Sie die Datei im Stammverzeichnis Ihres Projektordners als .hgignore (den Punkt am Anfang beachten). Führen Sie dann eine weitere Statusprüfung durch:
hg status
Das .hgignore Die 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 exakte Dateinamen verwenden zu müssen und die Ergebnisse dann festzuschreiben.
hg add hg commit -u ian -m "Initial"
Überprüfen Sie das Protokoll, um sicherzustellen, dass das Commit erfolgreich war.
hg log
HINWEIS: Weitere Informationen zu hgignore-Dateien finden Sie hier.
Wenn Sie Ihr Repository mit anderen Entwicklern gemeinsam nutzen möchten, können Sie am einfachsten ein Remote-Repository auf einem Server erstellen und Ihre Änderungen dazu übernehmen.
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 bei einem Dienst für ein Konto angemeldet haben, erstellen Sie ein neues Repository mithilfe der Webschnittstelle.
Suchen Sie nach dem "Klonpfad" nach dem Erstellen. Es sollte ungefähr so aussehen:
hg klon 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 statt dessen Änderungen an das entfernte Repository senden. Dazu können wir die URL-Adresse am Ende der Klon-Zeichenfolge als Ziel für den Push-Befehl verwenden.
hg drücken Sie https://bitbucket.org/username/reponame
Mercurial vergleicht das lokale Repository mit dem Remote-Repository, um zu sehen, wie sich diese unterscheiden. Es wird feststellen, dass unser lokales Repository neuere Änderungen enthält, dass das Remote-Repository fehlt, und diese an das Remote-Repository sendet.
Sie werden jedoch zunächst aufgefordert, einen Benutzernamen und ein Kennwort einzugeben. Diese sollten dem Benutzernamen / der E-Mail-Adresse und dem Kennwort entsprechen, mit denen Sie sich beim Host-Service angemeldet haben.
Mercurial sollte melden, dass alle Änderungen erfolgreich übertragen wurden. Dies bedeutet, dass jeder, der von Ihrem Repository abhängig ist, jetzt von diesem "Abruf" profitieren kann, um Ihre Änderungen zu erhalten. Zuerst müssen sie das Repository klonen, um eine lokale Kopie zu erstellen.
hg klon https://bitbucket.org/username/reponame
Nehmen Sie dann die Änderungen vor, die Sie oder andere Personen im Laufe der Zeit vornehmen:
hg ziehen
Sie müssen dann ein "Update" durchführen, um sicherzustellen, dass Ihre Arbeitskopie aktualisiert wird:
hg update
Um jedoch Zeit zu sparen, können Sie das Pulling durchführen und alle Aktualisierungen mithilfe von durchführen -u Flagge:
hg ziehen -u
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) andere" Option statt der "(Lokal" Möglichkeit.
Es gibt mehrere umständliche Aspekte, wenn Sie dieselben Befehle immer wieder ausgeben müssen, z. B. müssen Sie beim Festschreiben daran denken, einen Benutzernamen anzugeben, jedes Mal, wenn Sie einen Druck ausführen, ein Kennwort einzugeben usw. Viele dieser Einstellungen können in den sogenannten Einstellungen gespeichert werden ein hgrc Datei. So erstellen Sie eine hgrc Datei, verwenden Sie Ihren bevorzugten Texteditor und geben Sie Folgendes ein:
[pfade] default = https://bitbucket.org/username/reponame
Dadurch wird Mercurial mitgeteilt, welcher Pfad standardmäßig für Push- und Pull-Befehle verwendet werden soll. Stellen Sie sicher, dass Sie diese falsche Adresse durch die reale Adresse in Ihrem Remote-Repository ersetzen. Geben Sie anschließend Folgendes ein:
[ui] Benutzername = Vorname Nachname
Dadurch wird Mercurial mitgeteilt, welcher Benutzername standardmäßig beim Festschreiben verwendet werden soll. Ersetzen Sie dies erneut durch Ihre korrekten Anmeldeinformationen und stellen Sie sicher, dass die E-Mail-Adresse der Adresse entspricht, mit der Sie sich angemeldet haben. Zum Schluss geben Sie ein:
[auth] host.prefix = bitbucket.org host.username = Benutzername host.password = Kennwort host.schemes = http https
Dadurch wird Mercurial mitgeteilt, welche Anmeldeinformationen verwendet werden sollen, wenn Sie zu einem sicheren Remote-Repository wechseln, sodass Sie nicht jedes Mal einen Benutzernamen und ein Kennwort eingeben müssen, wenn Sie Push oder Pull ausführen. Stellen Sie sicher, dass Sie das Präfix durch den kürzestmöglichen Teil der Adresse Ihres Hosts ersetzen http: //
Protokoll im Präfix entweder. Ersetzen Sie als Nächstes den Benutzernamen und das Kennwort durch den, den Sie bei Ihrem Host angemeldet haben. Das Schema teilt Mercurial mit, mit welchen Protokollen versucht wird, eine Verbindung herzustellen.
Speichern Sie schließlich die Datei als hgrc (ohne Punkt oder Erweiterung am Ende) Innerhalb das .hg Ordner in Ihrem Repository. Sie müssen jetzt nicht mehr manuell Benutzernamen, Kennwörter oder Pfade angeben, wenn Sie Befehle ausgeben.
Die Versionskontrolle mag für Uneingeweihte etwas entmutigend erscheinen, aber der Aufwand lohnt sich. Es gibt Ihnen die Gewissheit, zu wissen, dass Sie ein defektes Projekt jederzeit wieder an einen Punkt rollen können, an dem es zuvor gearbeitet hat. Die Verwendung von Remote-Repositorys bedeutet auch, dass Code nicht nur für Teammitglieder freigegeben werden kann. Das Wiederherstellen des Projekts nach einem katastrophalen Ereignis (wie beispielsweise einem Festplattenausfall) ist einfach.
Um mehr über die verteilte Versionskontrolle und Mercurial zu erfahren, empfehle ich dringend den Besuch von Hg Init. In einer Reihe von Artikeln werden die Versionskontrollpraktiken und Mercurial-Funktionen ausführlich erläutert. Es ist kurz, sehr informativ, leicht zu lesen, leicht verständlich und sogar ein bisschen komisch.