Was ist Sourcetree?

Sourcetree ist eine grafische Benutzeroberfläche für Git und Mercurial. Es ermöglicht Dir, Deine Repositories visuell zu verwalten, ohne ständig Befehle in der Konsole eintippen zu müssen. Du kannst Branches erstellen, Merges durchführen, Stashes verwalten oder Rebase-Aktionen starten – alles per Mausklick.

Die wichtigsten Features im Überblick

• Klar strukturierte Oberfläche: Du siehst auf einen Blick, was in Deinem Projekt passiert – von Branches über Commits bis hin zu Merge-Konflikten.
• Branch-Management: Erstelle, verwalte und merge Branches schnell und visuell. Ideal für Feature-Branches und Git-Flow.
• Staging & Commit: Wähle gezielt aus, welche Änderungen Du stagen willst und formuliere Deine Commit-Nachrichten direkt im Interface.
• Submodule-Unterstützung: Auch komplexe Projekte mit Submodulen lassen sich bequem verwalten.
• Integration mit Bitbucket, GitHub & Co.: Repositories lassen sich direkt aus der Cloud klonen und pushen.

Für wen eignet sich Sourcetree?

Sourcetree ist sowohl für Git-Neulinge als auch für erfahrene Entwickler ein nützliches Tool. Anfänger profitieren vom visuellen Feedback, das hilft, Git-Konzepte besser zu verstehen. Profis schätzen die schnelle Übersicht bei komplexen Repositories und die Möglichkeit, Fehlerquellen wie Merge-Konflikte frühzeitig zu erkennen.

Sourcetree vs. Kommandozeile

Die Kommandozeile bleibt weiterhin mächtig – aber nicht jeder braucht oder will sie ständig nutzen. Sourcetree bietet eine komfortable Alternative mit vielen Funktionen, ohne auf Flexibilität zu verzichten. Und wenn Du willst, kannst Du jederzeit auch Shell-Befehle aus dem Tool heraus aufrufen.

Fazit: Effizientes Git-Management mit Stil

Sourcetree ist ein solides, durchdachtes Tool, das Git-Workflows deutlich übersichtlicher macht. Es ist kostenlos, leistungsfähig und erleichtert sowohl den Einstieg in Git als auch die tägliche Arbeit an komplexen Projekten. Wenn Du Deine Git-Repos effizient und visuell verwalten möchtest, solltest Du Sourcetree definitiv ausprobieren.

Der Beitrag Sourcetree – Git-Management mit Komfort erschien zuerst auf CEOsBay.

Git wurde ursprünglich von Linus Torvalds im Jahr 2005 für die Entwicklung des Linux-Kernels entwickelt, wobei andere Kernel-Entwickler zur anfänglichen Entwicklung wesentliche Beiträge geleistet haben. Seit 2005 ist Junio Hamano der Hauptverantwortliche. Wie bei den meisten anderen verteilten Versionskontrollsystemen und im Gegensatz zu den meisten Client-Server-Systemen ist jedes Git-Verzeichnis auf jedem Computer ein vollwertiges Repository mit einer vollständigen Historie und vollständigen Versionsverfolgungsfunktionen, unabhängig vom Netzwerkzugang oder einem zentralen Server. Git ist, wie Anfangs angesprochen, freie und Open Source Software, die unter der GPL-2.0-Lizenz vertrieben wird.

Eine kurze Anekdote über Git und dessen Abbreviatur

Linus Torvalds witzelte sarkastisch über den Namen git (was im britischen Slang „unangenehme Person“ bedeutet): „Ich bin ein egoistischer Mistkerl und benenne alle meine Projekte nach mir selbst. Erst „Linux“, jetzt „Git“. Die Manpage beschreibt Git als „the stupid content tracker“ Die Read-me-Datei des Quellcodes führt weiter aus:
„Git“ kann alles Mögliche bedeuten, je nach Laune (Ich werde dies in der englischen Sprache belassen, da es so wahrscheinlich mehr Sinn macht 😉 ).

• Random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of „get“ may or may not be relevant.
• Stupid. Contemptible and despicable. Simple. Take your pick from the dictionary of slang.
• „Global information tracker“: you’re in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
• „Goddamn idiotic truckload of sh*t“: when it breaks.

Um Git zu verstehen sind im Prinzip 8 Begriffe relevant. Repository (Kurz: Repo), die Versionskontrolle, Fork bzw. Forking (Gabel bzw. Gabelung), Branch (Verzweigung), Stage (Phase oder Stadium), Modified (modifiziert), Commit (Verbindlichkeit) und Merge (Zusammenführung). Diese Begriffe werde ich nachfolgend beschreiben.

Was ist eine Repository?

Eine Repository, kurz Repo genannt, ist ein Speicherort für Softwarepakete. Oft wird auch ein Inhaltsverzeichnis zusammen mit Metadaten (Metainformationen bzw. -daten sind strukturierte Daten, die Informationen über Merkmale anderer Daten enthalten) gespeichert. Eine Software-Repository wird in der Regel von Source-Control-Managern (SCM) oder Repository-Managern (Ein Repository-Manager ist eine dedizierte Server-Anwendung, die für die Verwaltung von Repositories mit binären Komponenten entwickelt wurde) verwaltet – Dazu teilweise mehr in der Versionskontrolle und in späteren Beiträgen. Paketmanager ermöglichen die automatische Installation und Aktualisierung von Repositories (Deshalb auch „Pakete“ genannt).

Viele Organisationen und Softwarehersteller unterhalten zu diesem Zweck Server im Internet, teilweise kostenlos oder gegen eine Gebühr. Repositories können können verschiedene Programmiersprachen, Betriebssysteme, Spiele oder andere Anwendungen sowie Dokumente und Daten beherbergen. Die Betreiber solcher Repositories stellen in der Regel ein Paketverwaltungssystem zur Verfügung. Folglich Werkzeuge, mit denen Softwarepakete aus den Repositories gesucht, installiert und anderweitig bearbeitet werden können. Viele Linux-Distributionen (Der Begriff Distribution stammt aus dem Lateinischen „distributio“ und hat im Zusammenhang mit Software zwei unterschiedliche Bedeutungen: Softwarepaketierung und Softwareverteilung) verwenden z. B. das Advanced Packaging Tool (APT), das häufig in Debian-basierten Distributionen zu finden ist oder yum in Red Hat-basierten Distributionen. Es gibt auch mehrere unabhängige Paketverwaltungssysteme, wie z. B. pacman, dass in Arch Linux verwendet wird und equo, welches in Sabayon Linux zu finden ist. Ich bin primär mit Debian-basierten Distributionen unterwegs. Werde ich aber in zukünftigen Beiträgen ausführlicher thematisieren.

Was ist Versionskontrolle?

Die Versionskontrolle unterstützt Entwickler bei der Verfolgung und Verwaltung von Änderungen am Quellcode eines Softwareprojekts. Wenn ein Projekt und die Anzahl der Programmierer wachsen, wird die Versionskontrolle unabdingbar. Doch in der Regel kommen sowohl bei kleineren als auch größeren Softwareprojekten mehrere Personen zum Einsatz, die gemeinsam an dem Quellcode arbeiten. Wenn man beispielsweise als Core-Entwickler an einem bestimmten Teil der Codebasis arbeiten möchte, ist es nicht förderlich oder effizient, wenn der Quellcode direkt bearbeitet wird, da zeitgleich noch andere die an dem Projekt beteiligt sind und daran arbeiten. Dies kann am Ende des Tages für ein enormes Durcheinander sorgen 😀

Da man auf dieses Durcheinander gut verzichten kann, arbeitet man als Entwickler mit einer Versionskontrolle „sicher“ durch branching (Verzweigungen) und merging (Zusammenführungen). „Sicher“ in Anführungszeichen, da es auch da einige Stolpersteine gibt 😉

Beim branching dupliziert ein Entwickler den Teil des Quellcodes (Das so genannte Repository bzw. die Repo), der für ihn relevant ist und kann die Änderungen genau an diesem Teil des Codes vornehmen, ohne den Rest des Projekts zu beeinträchtigen. Sobald der Entwickler seinen Teil des Codes ordnungsgemäß fertiggestellt hat, kann er diesen Code wieder in den Hauptquellcode mergen (einbinden), um es offiziell zu machen. All diese Änderungen werden protokolliert, kommentiert und können bei Bedarf eingesehen, kontrolliert oder rückgängig gemacht werden.

Was ist Fork. bzw. Forking?

Ein Fork ist eine Kopie einer Repository. Das Forken einer Repository ermöglicht es, frei mit Änderungen zu experimentieren, ohne das Originalprojekt zu beeinträchtigen. Dieser Begriff wird auch anderweitig genutzt, doch darauf werde ich jetzt nicht weiter eingehen 😀

Was ist Branch bzw. Branching?

Ein Branch (Zweig) ist ein hervorstehender Teil eines Baumes. Etwas, dass aus einem Hauptteil herausragt. So, auch in unserem Kontext. Ein Zweig stellt eine unabhängige Entwicklungslinie dar. Zweige dienen als Abstraktion für den Prozess der Bearbeitung (Stage/Commit). Man kann sie sich als eine Möglichkeit vorstellen, ein neues Arbeitsverzeichnis, einen Bereitstellungsbereich und/oder einen Projektverlauf anzufordern.

Was ist Modified bzw. Modifying?

Modified (Geändert) bedeutet, dass die Datei(en) geändert wurden aber noch nicht in die Datenbank bzw. Repository übertragen wurden.

Was ist Stage bzw. Staging?

Staged (Phase/Stadium) bedeutet, dass eine geänderte Datei in ihrer aktuellen Version markiert wurde, um sie in dem nächsten Commit-Snapshot (Schnappschuss) zu übernehmen.

Was ist Commit bzw. Committing ?

Commits (Verbindlichkeiten) sind die zentralen Bausteineinheiten einer Git-Projektzeitleiste. Sie können als Schnappschüsse oder Meilensteine entlang der Zeitachse eines Git-Projekts betrachtet werden. Commits werden mit dem Befehl „git commit“ erstellt, um den Zustand eines Projekts zu diesem Zeitpunkt festzuhalten. Im Endeffekt wie das Zwischenspeichern mit F5 bei Spielen oder Strg + S bei der regulären Arbeit am Computer. In der Betrachtungsweise einiger interessanter und manchmal nervtötender Zeitgenossen – Lediglich etwas fundamentaler 😉

Merge

Mit dem Merging-Befehl fügt Git einen geforkten (aufgegabelten) Verlauf wieder zusammen. Mit dem Befehl „git merge“ kann man die unabhängigen Entwicklungslinien, die mit dem Befehl „git branch“ erstellt wurden, in einen einzigen Zweig integrieren.

Fazit

Alles in allem sollte dies für eine kurze Erklärung reichen. In naher Zukunft werde ich auch ein Tutorial über die Nutzung von Git schreiben. Sicherlich gibt es heutzutage auch kommerzielle Cloud-Lösungen wie GitHub oder GitKraken, die diese Schritte auf wenige Mausklicks reduzieren und so eine nahtlosere Zusammenarbeit ohne etwaige Vorkenntnisse ermöglichen, doch dies werde ich auch in zukünftigen Beiträgen thematisieren.

Der Beitrag Git – Die Codeverwaltung für effiziente Zusammenarbeit revolutionieren erschien zuerst auf CEOsBay.