Mhorghinach
Member
- Registriert
- 10.05.2011
- Beiträge
- 33
Wie ich erfreut festgestellt habe setzt es sich mehr und mehr durch, auch für Mods Versionskontrollsysteme zu verwenden. Auf mich wirkt es aber so, dass die Verwendung eines solchen Systems für viele neu ist und da ich im Forum hierzu nichts gefunden habe, dachte ich mir, ich schreib mal einen kurzen Guide, wie sich solch ein System im Kontext des Moddings einsetzen läßt.
1. Was ist Git
Git - the stupid content tracker ist ein Versionskontrollsystem und dient der Verwaltung und Dokumentation unterschiedlicher Versionen einer Datei. Solche Systeme werden seit mehr als 40 Jahren bei der Softwareentwicklung eingesetzt (siehe https://de.wikipedia.org/wiki/Source_Code_Control_System)
Git wurde von Linus Torvalds 2005 für seinen Linux Kernel entwickelt und ist freie Software. Es wurde insbesondere für eine verteilte Entwicklung, wie sie auch bei uns stattfindet, entwickelt und zeichnet sich durch seine hohe Effizienz und seine Sicherheit gegen unbeabsichtigte und böswillige Verfälschung aus.
Von anderen Versionskontrollsystemen unterscheidet es sich dadurch, dass nicht-lineare und verteilte Entwicklung gefördert und es nicht notwendigerweise einen einzelnen, zentralen Server gibt, der das gesamte Repository vorhält, stattdessen hat jeder der an einem Projekt mitarbeitet eine lokale Kopie des Repositories auf seinem Rechner. Außerdem ist der Transfer von Daten zwischen den Repositories verschiedener Benutzer möglich.
2. Installation von Git
Git besteht aus einer Reihe von Kommandozeilenwerkzeugen, sowie einem einfachen GUI Werkzeug. Komfortablere GUIs gibt es auf der Git Homepage für alle gängigen Betriebssysteme. Für Windows hab ich SourceTree und GitEye ausprobiert.
Für alle die lieber auf der Kommandozeile arbeiten:
Macs habe ich jetzt nicht berücksichtigt, aus dem einfachen Grund, dass ich keinen zur Verfügung habe ;-P Es gibt aber auf der Homepage von Git sowohl Links für die Kommandozeilentools, als auch für GUIs.
3. Repositories
Es gibt mehrere große und öffentliche Repositories, auf denen man Quellcode speichern kann. Die bekanntesten dürften Github und bitbucket sein.
Auf beiden ist die Mitgliedschaft kostenlos, sie benötigt lediglich eine Registrierung und beide warten mit ähnlichen Features auf. Es gibt bereits einige Projekte innerhalb der BG Modding Community, die bei einem dieser Hoster zu finden sind, etwa das BigWorldSetup oder BG1NPC.
4. Von branches, forks, pulls und commits - ein kleines Git Glossar
Wer mit Versionskontrollsystemen nicht vertraut ist, wird zu Anfang mit viel neuer Terminologie konfrontiert. Bevor ich zum Kern dieses Guides komme, möchte ich die wichtigsten Konzepte und Begriffe anschneiden. Ich werde diese Konzepte im nächsten Abschnitt anhand eines Beispiels konkretisieren.
5. Workflows
Für die Arbeit im Team mit Git haben sich einige Workflows etabliert, die je nach Größe des Teams, wie eng die Entwickler zusammenarbeiten, wie sehr den Einzelnen vertraut wird, ob ein zentraler Server verwendet wird und anderer Rahmenbedingungen verschiedene Workflows entwickelt. Für lose Teams, wie wir sie hier antreffen, ist der Forking Workflow gut geeignet. Ich werde ihn im Folgenden anhand eines konkreten, aber leicht fiktiven Beispiels zu verdeutlichen versuchen.
Voraussetzungen und Annahmen:
Unser Projekt ist das BG1NPC Übersetzungsprojekt. Maintainer des Projektes sei M. Diese Person beteiligt sich für das Beispiel nicht an der Übersetzung, sondern ist für das Release der Übersetzungen gegenüber dem Maintainer des BG1NPC Projektes verantwortlich. Es gibt eine Übersetzerin A, sowie eine Korrekturleserin B.
Zuerst erstellt A einen neuen branch (ich nenn' ihn mal: trans) und wechselt auf diesen. Sie hat nun zwei Zweige in dem Projekt (master und trans), wobei trans der aktive ist. Jetzt nimmt sie die Übersetzung vor. Sobald sie mit dem Ergebnis zufrieden ist, committed sie die geänderten Dateien und gibt dabei einen aussagekräftigen Kommentar an. Danach pusht sie den aktuellen branch auf den Server. Erst jetzt gibt es auch auf dem Server beide Zweige. Danach informiert sie B, dass die Übersetzung bereitsteht.
Nun pullt B den branch trans von A in ihre Arbeitskopie und macht ihn aktuell. Sie liest sich die Übersetzung durch, macht ihre Korrekturen, commited alles und pusht es wieder zurück auf ihre remote Kopie auf dem Server. Anschließend informiert sie A, dass sie Änderungen an der Übersetzung vorgenommen hat. A pullt die Änderungen in ihre Kopie und schaut sie sich an. Das geht so lange hin und her, bis beide mit dem Ergebnis zufrieden sind.
Jetzt merged A ihren branch trans in den master branch und pusht master auf den Server. Danach können beide den branch trans löschen. Im Anschluß wird M darüber informiert, dass eine neue Übersetzung bereit liegt. M pullt sich die Änderungen von A und merged diese in ihren master. Nun kann M entweder warten, bis sie einige Übersetzungen gesammelt hat, oder direkt den Maintainer von BG1NPC kontaktieren und ihm mitteilen, dass er die neuen Übersetzungen pullen und in das Repository integrieren soll, womit sie bei der nächsten Release zur Verfügung stehen.
Ich weiß, dass sich das alles relativ kompliziert anhört, ist aber alles halb so schlimm! Wenn man es einige Male gemacht hat, wird es selbstverständlich.
6. Ressourcen
7. Schluss
Ich hoffe, dass dieser Guide etwas dazu beitragen kann, die Verwendung von git zu vereinfachen und euch nicht noch mehr verwirrt hat
Idealerweise würde jeder Mod auf einem öffentlichen Git Repository gehostet, wodurch das Updaten, etwa durch BWS, extrem vereinfacht und vollständig automatisiert werden könnte.
Kritik, Anregungen, Fragen sind ausdrücklich erwünscht.
1. Was ist Git
Git - the stupid content tracker ist ein Versionskontrollsystem und dient der Verwaltung und Dokumentation unterschiedlicher Versionen einer Datei. Solche Systeme werden seit mehr als 40 Jahren bei der Softwareentwicklung eingesetzt (siehe https://de.wikipedia.org/wiki/Source_Code_Control_System)
Git wurde von Linus Torvalds 2005 für seinen Linux Kernel entwickelt und ist freie Software. Es wurde insbesondere für eine verteilte Entwicklung, wie sie auch bei uns stattfindet, entwickelt und zeichnet sich durch seine hohe Effizienz und seine Sicherheit gegen unbeabsichtigte und böswillige Verfälschung aus.
Von anderen Versionskontrollsystemen unterscheidet es sich dadurch, dass nicht-lineare und verteilte Entwicklung gefördert und es nicht notwendigerweise einen einzelnen, zentralen Server gibt, der das gesamte Repository vorhält, stattdessen hat jeder der an einem Projekt mitarbeitet eine lokale Kopie des Repositories auf seinem Rechner. Außerdem ist der Transfer von Daten zwischen den Repositories verschiedener Benutzer möglich.
2. Installation von Git
Git besteht aus einer Reihe von Kommandozeilenwerkzeugen, sowie einem einfachen GUI Werkzeug. Komfortablere GUIs gibt es auf der Git Homepage für alle gängigen Betriebssysteme. Für Windows hab ich SourceTree und GitEye ausprobiert.
- SourceTree wird vom Betreiber von bitbucket (Atlassian) zur freien Benutzung bereitgestellt. Ich finde es intuitiv und einfach zu bedienen und es beinhaltet alle wichtigen Funktionen. Git ist hierbei integriert und es ist keine separate Installation von Git erforderlich.
- GitEye benötigt Java und basiert auf der Eclipse Entwicklungsumgebung. Es ist mächtiger als SourceTree, allerdings finde ich es überladen und die Bedienung weniger intuitiv. Es scheint mir eher für Programmierer geeignet, die sowieso Eclipse verwenden und das Tool in die Arbeitsumgebung integrieren können. Auch hier ist git in die GUI integriert und muss nicht separat installiert werden. Da es auf Java basiert, ist es auf allen Platformen ausführbar, die Java unterstützen.
- Auf Linux gibt es gitg, ein Tool für Gnome, das man einfach mit dem Paketmanager installieren kann.
Für alle die lieber auf der Kommandozeile arbeiten:
- Für Windows es Git für Windows welches mit einer bash Shell daherkommt, oder man kann alternativ Cygwin installieren, wo git mit dabei ist.
- Auf vielen *nix Systemen dürfte Git bereits installiert sein, ansonsten pullt man es einfach mit dem distributionseigenen Paketmanager (rpm, yum, apt, pkgconfig, emerge) in das System.
Macs habe ich jetzt nicht berücksichtigt, aus dem einfachen Grund, dass ich keinen zur Verfügung habe ;-P Es gibt aber auf der Homepage von Git sowohl Links für die Kommandozeilentools, als auch für GUIs.
3. Repositories
Es gibt mehrere große und öffentliche Repositories, auf denen man Quellcode speichern kann. Die bekanntesten dürften Github und bitbucket sein.
Auf beiden ist die Mitgliedschaft kostenlos, sie benötigt lediglich eine Registrierung und beide warten mit ähnlichen Features auf. Es gibt bereits einige Projekte innerhalb der BG Modding Community, die bei einem dieser Hoster zu finden sind, etwa das BigWorldSetup oder BG1NPC.
4. Von branches, forks, pulls und commits - ein kleines Git Glossar
Wer mit Versionskontrollsystemen nicht vertraut ist, wird zu Anfang mit viel neuer Terminologie konfrontiert. Bevor ich zum Kern dieses Guides komme, möchte ich die wichtigsten Konzepte und Begriffe anschneiden. Ich werde diese Konzepte im nächsten Abschnitt anhand eines Beispiels konkretisieren.
- clone: Das erstmalige Herunterladen eines Repositories auf den lokalen Rechner wird als klonen bezeichnet. Hierbei wird in der Regel der master branch geklont.
- fork: Ein fork bezeichnet einen clone eines externen Repositories auf seinen eigenen Account. Man kann von jedem öffentlichen Projekt eines Hosters einen fork erstellen und darin, unabhängig vom ursprünglichen Entwickler, herumspielen.
- master: Mit master wird in der Regel der Hauptzweig der Entwicklung bezeichnet. Dies ist eine Konvention und die Standardeinstellung von git, dem Hauptzweig kann aber ein anderer Name zugewiesen werden. Oft wird nicht in diesem Zweig selbst entwickelt, sondern in branches, welches von ihm abgeleitet werden, der master dient dabei mehr der Integration neuer Entwicklungen/Features und dem Releasemanagement.
- branch: Ein branch ist ein nebenläufiger Entwicklungszweig. Zu Beginn eines neuen Entwicklungsabschnitts, etwa am Anfang eines neuen Releasezyklus' oder wenn ein neues Feature implementiert werden soll, wird ein neuer branch vom master abgeleitet, in welchem die Entwicklung stattfindet. Es kann zu einer bestimmten Zeit viele branches geben, die alle unabhängig voneinander entwickelt werden. Nach Abschluß der Arbeiten wird der branch in den master gemerged und damit die neue Entwicklung für das nächste Release verfügbar.
- changeset: Eine Reihe von Änderungen, die zwar an verschiedenen Dateien durchgeführt werden, aber logisch zusammengehören. Commits werden häufig in changesets zusammengefasst, damit logisch zusammengehörende Änderungen gemeinsam erfasst und geloggt werden.
- commit: Nach Abschluß zusammengehörender Änderungen, werden die beteiligten Dateien comitted und dabei im aktuellen branch veröffentlich. Dabei gibt man einen Kommentar an, der die Änderungen beschreibt und es wird von git ein eindeutiger Hashwert für den Commit erzeugt. Anhand dieses Hashes ist jeder Commit explizit abrufbar. Das comitten geschieht ausschließlich auf der lokalen Kopie des Codes.
- merge: Mit merge ist die Integration eines branches zurück in den master branch gemeint, nachdem die Entwicklung und das Testen abgeschlossen sind. Der branch wird daraufhin in vielen Fällen gelöscht, da er nicht mehr benötigt wird und dadurch Speicherplatz wieder freigegeben wird.
- pull: Ein pull bezeichnet die Anforderung einer Synchronisation eines entfernten Repositories mit dem eigenen. Wenn etwa zwei Entwickler an einem Projekt arbeiten, jeder in seinem eigenen fork und einer der beiden veröffentlich seine Änderungen, kann der andere diese Änderungen pullen und damit in seinen fork integrieren.
- push: Das Gegenteil von pull. Beim push schiebe ich meine lokalen Änderungen z.B. auf das externe Repository beim Hoster und stelle sie damit öffentlich zur Verfügung.
5. Workflows
Für die Arbeit im Team mit Git haben sich einige Workflows etabliert, die je nach Größe des Teams, wie eng die Entwickler zusammenarbeiten, wie sehr den Einzelnen vertraut wird, ob ein zentraler Server verwendet wird und anderer Rahmenbedingungen verschiedene Workflows entwickelt. Für lose Teams, wie wir sie hier antreffen, ist der Forking Workflow gut geeignet. Ich werde ihn im Folgenden anhand eines konkreten, aber leicht fiktiven Beispiels zu verdeutlichen versuchen.
Voraussetzungen und Annahmen:
- Alle am Projekt beteiligten haben einen Account bei einem Hoster.
- Es wird angenommen, dass die Maintainer eines Projektes (Mods) dieses öffentlich gehostet haben. Sie sind für die Releases des Projektes verantwortlich.
- Weiter wird angenommen, dass die neueste Release frisch veröffentlicht wurde und seither noch keine Änderungen am Projekt stattgefunden haben.
Unser Projekt ist das BG1NPC Übersetzungsprojekt. Maintainer des Projektes sei M. Diese Person beteiligt sich für das Beispiel nicht an der Übersetzung, sondern ist für das Release der Übersetzungen gegenüber dem Maintainer des BG1NPC Projektes verantwortlich. Es gibt eine Übersetzerin A, sowie eine Korrekturleserin B.
Zuerst erstellt A einen neuen branch (ich nenn' ihn mal: trans) und wechselt auf diesen. Sie hat nun zwei Zweige in dem Projekt (master und trans), wobei trans der aktive ist. Jetzt nimmt sie die Übersetzung vor. Sobald sie mit dem Ergebnis zufrieden ist, committed sie die geänderten Dateien und gibt dabei einen aussagekräftigen Kommentar an. Danach pusht sie den aktuellen branch auf den Server. Erst jetzt gibt es auch auf dem Server beide Zweige. Danach informiert sie B, dass die Übersetzung bereitsteht.
Nun pullt B den branch trans von A in ihre Arbeitskopie und macht ihn aktuell. Sie liest sich die Übersetzung durch, macht ihre Korrekturen, commited alles und pusht es wieder zurück auf ihre remote Kopie auf dem Server. Anschließend informiert sie A, dass sie Änderungen an der Übersetzung vorgenommen hat. A pullt die Änderungen in ihre Kopie und schaut sie sich an. Das geht so lange hin und her, bis beide mit dem Ergebnis zufrieden sind.
Jetzt merged A ihren branch trans in den master branch und pusht master auf den Server. Danach können beide den branch trans löschen. Im Anschluß wird M darüber informiert, dass eine neue Übersetzung bereit liegt. M pullt sich die Änderungen von A und merged diese in ihren master. Nun kann M entweder warten, bis sie einige Übersetzungen gesammelt hat, oder direkt den Maintainer von BG1NPC kontaktieren und ihm mitteilen, dass er die neuen Übersetzungen pullen und in das Repository integrieren soll, womit sie bei der nächsten Release zur Verfügung stehen.
Ich weiß, dass sich das alles relativ kompliziert anhört, ist aber alles halb so schlimm! Wenn man es einige Male gemacht hat, wird es selbstverständlich.
6. Ressourcen
- Dokumentation auf der Git Homepage
- Pro Git, ein ausführliches Buch zu git
- Git Tutorials bei Atlassian
7. Schluss
Ich hoffe, dass dieser Guide etwas dazu beitragen kann, die Verwendung von git zu vereinfachen und euch nicht noch mehr verwirrt hat
Idealerweise würde jeder Mod auf einem öffentlichen Git Repository gehostet, wodurch das Updaten, etwa durch BWS, extrem vereinfacht und vollständig automatisiert werden könnte.
Kritik, Anregungen, Fragen sind ausdrücklich erwünscht.