Egal ob Web- oder App-Entwickler: Git hilft allen Codern, Änderungen an Dateien zu tracken und zu verwalten. Aber wie genau funktioniert Git, und warum sollten Sie es nutzen, um Plug-ins für QSC Communities zu entwickeln oder Dateien zu verwalten?
Was ist Git?
Git ist das weltweit am meisten genutzte System zur Versionskontrolle. Es protokolliert alle Änderungen, die Sie an einer Datei vornehmen. Der Vorteil daran ist, dass Sie immer ein Protokoll aller Änderungen zur Hand haben und bei Bedarf zu früheren Dateiversionen zurückkehren können. Git vereinfacht zudem die Zusammenarbeit mit anderen Entwicklern, weil deren Änderungen alle in einer Quelldatei zusammengefasst werden. Dadurch ist Git ideal für das gemeinsame Schreiben von Code, aber auch für viele andere Dateiformate. Egal ob Sie also Ihren Code allein schreiben oder im Team arbeiten: Git ist sehr nützlich für alle Entwicklungsprojekte.
Die Git Software läuft grundsätzlich lokal. Alle Dateien und deren Versionshistorie werden auf Ihrem Rechner gespeichert. Sie können jedoch zusätzlich Online-Hosts wie GitHub oder Bitbucket nutzen, um Kopien der Dateien und ihrer Historie online zu speichern. Ein derartiger zentraler Ort im Netz, an dem Sie all ihre Versionen speichern und von dem Sie den Versionsverlauf anderer User herunterladen können, vereinfacht die Zusammenarbeit erheblich. Git kann Änderungen automatisch konsolidieren, sodass zwei Personen sogar an unterschiedlichen Abschnitten derselben Datei arbeiten und ihre Änderungen später zusammenführen können, ohne dass etwas verloren geht.
Wie Sie Git nutzen können
Git lässt sich auf folgende Arten nutzen:
- Über eine Kommandozeile (Command Line Input), auch Terminal genannt
- Als Desktopanwendung mit einer grafischen Benutzeroberfläche wie Sourcetree (s.u.) oder über die Desktop-Version von GitHub. In diesem Artikel von Kevin über das Teilen von Dateien per SourceTree erfahren Sie zudem, wie Sie Git mit BitBucket kombinieren können.
- Als Erweiterung Ihres Code-Editors. VS Code hat zum Beispiel eine Git-Erweiterung, mit der Sie lokale Dateien in die Cloud laden können. Lesen Sie dazu auch die Setup Guides von BitBucket und GitHub.
Git Repositories
Ein Git-Repository (oder kurz repo) enthält alle Dateien eines Projekts und die gesamte Versionshistorie. Mit Git können Sie jeden beliebigen Ordner (etwa den Root-Ordner einer Website) in ein Repository verwandeln. Dabei wird ein .git-Unterordner erstellt, der alle Git-Metadaten für die Versionshistorie enthält.
Stage- & Commit-Dateien
Stellen Sie sich vor, dass Git alle Änderungen an einer Datei in einer Liste notiert. Wie erfährt Git aber nun, dass eine Änderung aufgezeichnet werden soll? Jede erfasste Änderung an einer oder mehreren Dateien nennt man einen „Commit“.
Bevor ein Commit getätigt wird, muss man Git mitteilen, welche Dateien betroffen sind. Dieser Vorgang wird als „Staging“ bezeichnet und mit dem Terminal-Befehl add durchgeführt. Warum ist dieser Schritt notwendig? Wieso kann eine Datei nicht direkt ‚committed‘ werden? Nehmen wir an, dass Sie an einem Projekt mit zwei Dateien arbeiten, aber nur eine davon für einen Commit bereit ist. Dann wollen Sie auch nur diesen einen Commit durchführen, nicht zwingend beide. In diesem Fall können Sie den add-Befehl von Git nutzen. Mit diesem Befehl werden Dateien zum Staging-Bereich hinzugefügt, von wo aus sie dann im Verbund ‚committed‘ werden können.
Remote-Repositories (auf GitHub & Bitbucket)
Wenn Sie eine Kopie Ihres Git-Repository über einen Host wie GitHub oder Bitbucket online speichern, erhalten Sie dadurch einen zentralen Ort, an dem Sie all ihre Versionen sammeln und von dem Sie den Versionsverlauf anderer User herunterladen können – was die Zusammenarbeit mit anderen erheblich erleichtert. Ist ein solches Remote-Repository eingerichtet, laden Sie Ihre Dateien und deren Versionshistorie dort hoch. Wenn jemand Änderungen an einem Remote-Repository vornimmt, können Sie diese Änderungen wiederum in Ihr lokales Repository laden (dieser Vorgang wird „Pull“ genannt).
Branchen, Forken & Konsolidieren
Git ermöglicht Ihnen, von der ursprünglichen Codebase abzuweichen („Branching“). Diese Funktion macht die Zusammenarbeit noch leichter und sorgt für einen flexibleren Workflow.
Hier ist ein Beispiel dafür, wie nützlich Branchen sein kann: Nehmen wir an, dass Sie an einer neuen Funktion für eine Website arbeiten. Sie erstellen einen neuen Branch und fangen an, ihn zu bearbeiten. Doch dann erhalten Sie eine Anfrage für eine Änderung an der Website, die so schnell wie möglich online gehen muss – und Sie haben die neue Funktion noch nicht fertiggestellt. In diesem Fall wechseln Sie einfach zum Master-Branch in Git, führen die Änderung durch und stellen sie online. Anschließend können Sie zum neuen Branch zurückkehren und die Arbeit daran abschließen. Wenn Sie fertig sind, konsolidieren Sie das neue Feature mit dem Master-Branch („Merging“). Dort sind danach sowohl das neue Feature als auch die zuvor getätigte Änderung vorhanden.
Wenn zwei Online-Branches (oder ein lokaler und ein Remote-Branch) zusammengeführt werden, gibt es hin und wieder Konflikte. So könnten Sie und ein anderer Entwickler beispielsweise unwissentlich am selben Teil einer Datei arbeiten. Nehmen wir an, der andere Entwickler lädt daraufhin seine Änderungen in das Remote-Repository hoch. Wenn Sie dann seine Änderungen wiederum in Ihr lokales Repository laden, entsteht ein Merging-Konflikt mit Ihrer eigenen Version. Glücklicherweise bietet Git eine Funktion zur Lösung solcher Konflikte: Ihnen werden beide Änderungen angezeigt, und Sie entscheiden, welche davon beibehalten werden soll. Wenn Branches zusammengeführt werden, muss Git lediglich die Unterschiede zwischen den getätigten Änderungen abgleichen.
Das sogenannte Forken hingegen ist ein deutlich komplexerer Vorgang. Wenn Forks zusammengeführt werden, muss Git zwei Codebases miteinander vergleichen, denn ein Fork ist eine Kombination aus zwei Versionen einer kompletten Codebase. Während beim Branchen nur etwas zu Ihrer bestehenden Struktur hinzugefügt wird, wird beim Forken eine vollständige Kopie Ihres Repository erstellt.
Wir empfehlen Nutzern das Forken, wenn Sie etwas zu einem fremden Code-Repository beitragen wollen und die Dateigröße des Repository kein Problem darstellt.
Pull Requests
Mit einer sogenannten Pull Request können Sie Änderungen von anderen Nutzern genehmigen lassen, bevor diese mit dem restlichen Code konsolidiert werden. Nehmen wir an, dass Sie ein Projekt verwalten. Ein Entwickler nimmt Änderungen an einem Branch vor oder entscheidet sich, das Repository zu forken. Dann möchte er den Branch bzw. den Fork mit dem Master-Repository konsolidieren. In diesem Fall kann er ein Pull Request vornehmen, woraufhin Sie eine Benachrichtigung erhalten, die Sie auffordert, den geänderten Code zu prüfen. Sie können die Änderungen kommentieren und entscheiden, ob die Konsolidierung stattfinden darf.
Mehr Infos über Git
Wir hoffen, dass Ihnen dieser Beitrag ein wenig dabei geholfen hat, Git und seine Vorteile für den Workflow zu verstehen. Sie können andernorts noch mehr über Git und dessen Nutzen im Zusammenhang mit Q-SYS Programmierungen lernen.
Hier sind ein paar weitere Links für Sie:
- Einführung in GitHub und Bitbucket
- Dateien mit GitHub und Bitbucket teilen (von Kevin Rhodus)
- Zusammenarbeit: Code forken mit GitHub oder Bitbucket