Was bedeutet Git
Was ist Git?
Das bei weitem am weitesten verbreitete moderne Versionskontrollsystem der Welt ist heute Git (mehr dazu Git Training) . Git ist ein ausgereiftes, aktiv gepflegtes Open-Source-Projekt, das ursprünglich im Jahr 2005 von Linus Torvalds, dem berühmten Schöpfer des Linux-Betriebssystemkerns, entwickelt wurde. Eine erstaunliche Anzahl von Softwareprojekten verlässt sich bei der Versionskontrolle auf Git, darunter sowohl kommerzielle Projekte als auch Open Source. Entwickler, die mit Git gearbeitet haben, sind im Pool der verfügbaren Softwareentwicklungstalente gut vertreten, und Git funktioniert gut auf einer Vielzahl von Betriebssystemen und IDEs (Integrated Development Environments).
Sicherheit von Git
Git wurde mit der Integrität des verwalteten Quellcodes als oberste Priorität entworfen. Der Inhalt der Dateien sowie die wahren Beziehungen zwischen Dateien und Verzeichnissen, Versionen, Tags und Commits, all diese Objekte im Git-Repository sind mit einem kryptographisch sicheren Hash-Algorithmus namens SHA1 gesichert. Dieser schützt den Code und die Änderungshistorie sowohl vor versehentlichen als auch böswilligen Änderungen und stellt sicher, dass die Historie vollständig nachvollziehbar ist.
Git ist ein De-facto-Standard
Git ist das am weitesten verbreitete Instrument seiner Art. Dies macht Git aus den folgenden Gründen attraktiv.
Sehr viele Entwickler haben bereits Git-Erfahrung, und ein beträchtlicher Anteil der Hochschulabsolventen hat möglicherweise nur mit Git Erfahrung. Während einige Organisationen die Lernkurve erklimmen müssen, wenn sie von einem anderen Versionskontrollsystem zu Git migrieren, müssen viele ihrer bestehenden und zukünftigen Entwickler nicht auf Git geschult werden.
Git ist ein sehr gut unterstütztes Open-Source-Projekt mit über einem Jahrzehnt solider Verwaltung. Die Projektbetreuer haben ein ausgewogenes Urteilsvermögen und eine ausgereifte Herangehensweise gezeigt, um die langfristigen Bedürfnisse der Benutzer mit regelmäßigen Releases zu erfüllen, die die Benutzerfreundlichkeit und Funktionalität verbessern. Die Qualität der Open-Source-Software lässt sich leicht überprüfen, und unzählige Unternehmen verlassen sich stark auf diese Qualität.
Schulungsbedarf bei Git
Eine häufig geäußerte Kritik an Git ist, dass sie schwer zu erlernen sein kann. Einige der Terminologie in Git wird für Neulinge neu sein und für Benutzer anderer Systeme kann die Git-Terminologie anders sein, z.B. hat revert in Git eine andere Bedeutung als in SVN oder CVS. Nichtsdestotrotz ist Git sehr leistungsfähig und bietet seinen Benutzern eine Menge Power. Zu lernen, diese Leistung zu nutzen, kann einige Zeit in Anspruch nehmen, aber wenn es einmal erlernt wurde, kann diese Leistung vom Team (siehe auch Team Seminare) genutzt werden, um die Entwicklungsgeschwindigkeit zu erhöhen. Zu Git passend findet sich eine [url=https://www.gfu.net/seminare-schulungen-kurse/testmanagement_sk92/git-einstieg-versionsverwaltung_s1664.html.]Git Schulung[/url].
Für die Teams, die aus einem nicht verteilten VCS kommen, mag es als eine gute Sache erscheinen, ein zentrales Repository zu haben, das sie nicht verlieren wollen. Doch obwohl Git als ein verteiltes Versionskontrollsystem (DVCS) konzipiert wurde, können Sie mit Git immer noch ein offizielles, kanonisches Repository haben, in dem alle Änderungen an der Software gespeichert werden müssen. Da mit Git das Repository jedes Entwicklers vollständig ist, muss seine Arbeit nicht durch die Verfügbarkeit und Leistung des "zentralen" Servers eingeschränkt werden. Bei Ausfällen oder wenn sie offline sind, können die Entwickler immer noch den vollständigen Projektverlauf einsehen. Da Git sowohl flexibel ist als auch verteilt wird, können Sie so arbeiten, wie Sie es gewohnt sind, aber die zusätzlichen Vorteile von Git nutzen, von denen Sie vielleicht nicht einmal merken, dass Sie sie vermissen.
Terminoly in Git
Branch
Ein Branch ist ein benannter Zeiger auf eine Übergabe. Das Auswählen eines Zweiges in der Git-Terminologie wird aufgerufen, um einen Zweig auszuchecken. Wenn Sie in einem bestimmten Zweig arbeiten, wird bei der Erstellung einer neuen Übertragung dieser Zeiger auf die neu erstellte Übertragung weitergeschaltet.
Jeder Commit kennt seine Eltern (Vorgänger). Nachfolger werden abgerufen, indem der Commit-Graph ausgehend von Zweigen oder anderen Referenzen, symbolischen Referenzen (z.B.: HEAD) oder expliziten Commit-Objekten durchlaufen wird. Auf diese Weise definiert ein Zweig seine eigene Linie von Nachfolgern im Gesamtversionsgraphen, der durch alle Commits im Repository gebildet wird.
Commit
Wenn Sie Ihre Änderungen in ein Repository "committen", wird ein neues Übertragungsobjekt im Git-Repository erstellt. Dieses Commit-Objekt identifiziert eindeutig eine neue Revision des Inhalts des Repositorys.
Diese Revision kann später abgerufen werden, z. B. wenn Sie den Quellcode einer älteren Version sehen möchten. Jedes Commit-Objekt enthält den Autor und den Committer. Dadurch ist es möglich, festzustellen, wer die Änderung vorgenommen hat. Der Autor und der Committer können verschiedene Personen sein. Der Autor hat die Änderung vorgenommen und der Committer hat die Änderung auf das Git-Repository angewendet. Dies ist bei Beiträgen zu Open-Source-Projekten üblich.
Head
HEAD ist ein symbolischer Verweis, der meistens auf den aktuell ausgecheckten Zweig verweist.
Manchmal zeigt der HEAD direkt auf ein Commit-Objekt, dies wird als losgelöster HEAD-Modus bezeichnet. In diesem Zustand wird bei der Erzeugung eines Commits kein Zweig verschoben.
Wenn Sie die Zweige wechseln, zeigt der HEAD-Zeiger auf den Zweigzeiger, der wiederum auf eine Übergabe zeigt. Wenn Sie eine bestimmte Übergabe auschecken, zeigt der HEAD-Zeiger direkt auf diese Übergabe.
Repository
Ein Repository enthält die Geschichte, die verschiedenen Versionen im Laufe der Zeit und alle verschiedenen Zweige und Tags. In Git ist jede Kopie des Repositorys ein vollständiges Repository. Wenn das Projektarchiv kein reines Projektarchiv ist, erlaubt es Ihnen, Revisionen in Ihren Arbeitsbaum auszuchecken und Änderungen durch das Erstellen neuer Übertragungen zu erfassen. Bare-Repositorys werden nur durch den Transport von Änderungen aus anderen Repositorys geändert.
In dieser Beschreibung wird der Begriff Repository verwendet, um von einem nicht bloßen Repository zu sprechen. Wenn von einem bloßen Repository die Rede ist, wird dies ausdrücklich erwähnt.
Tag
Ein Tag zeigt auf einen Commit, der eine Version des Git-Repositorys eindeutig identifiziert. Mit einem Tag können Sie einen benannten Punkt haben, zu dem Sie jederzeit zurückkehren können. Sie können zu jedem Punkt in einem Git-Repository zurückkehren, aber Tags machen es einfacher. Der Vorteil von Tags ist es, das Repository aus einem bestimmten Grund zu kennzeichnen, z.B. mit einer Veröffentlichung.
Zweige und Markierungen werden Zeiger genannt. Der Unterschied ist, dass sich Zweige beim Erstellen einer neuen Übergabe verschieben, während Markierungen immer auf dieselbe Übergabe zeigen. Tags können mit einem Zeitstempel und einer Nachricht versehen werden.
URL
Eine URL in Git bestimmt den Speicherort des Repositorys. Git unterscheidet zwischen fetchurl, um neue Daten von anderen Repositories zu erhalten, und pushurl, um Daten in ein anderes Repository zu schieben.
Technische Details eines Commit-Objekts
Dieses Commit-Objekt ist über einen Hash adressierbar ( SHA-1-Prüfsumme ). Dieser Hash wird basierend auf dem Inhalt der Dateien, dem Inhalt der Verzeichnisse, der vollständigen Historie bis zur neuen Übergabe, dem Committer, der Commit-Nachricht und verschiedenen anderen Faktoren berechnet.
Das bedeutet, dass Git sicher ist, Sie können eine Datei oder die Commit-Nachricht im Git-Repository nicht manipulieren, ohne dass Git bemerkt, dass der entsprechende Hash nicht mehr zum Inhalt passt.
Das Commit-Objekt verweist über ein Baumobjekt auf die einzelnen Dateien in dieser Übertragung. Die Dateien werden im Git-Repository als Blob-Objekte gespeichert und können von Git zur besseren Leistung und kompakteren Speicherung gepackt werden. Blobs werden über ihren SHA-1-Hash angesprochen.
Das Packen beinhaltet die Speicherung von Änderungen als Deltas, Komprimierung und Speicherung vieler Objekte in einer einzigen Pack-Datei. Pack-Dateien werden von einer oder mehreren Indexdateien begleitet, die den Zugriff auf einzelne Objekte, die in diesen Packs gespeichert sind, beschleunigen.
Das bei weitem am weitesten verbreitete moderne Versionskontrollsystem der Welt ist heute Git (mehr dazu Git Training) . Git ist ein ausgereiftes, aktiv gepflegtes Open-Source-Projekt, das ursprünglich im Jahr 2005 von Linus Torvalds, dem berühmten Schöpfer des Linux-Betriebssystemkerns, entwickelt wurde. Eine erstaunliche Anzahl von Softwareprojekten verlässt sich bei der Versionskontrolle auf Git, darunter sowohl kommerzielle Projekte als auch Open Source. Entwickler, die mit Git gearbeitet haben, sind im Pool der verfügbaren Softwareentwicklungstalente gut vertreten, und Git funktioniert gut auf einer Vielzahl von Betriebssystemen und IDEs (Integrated Development Environments).
Sicherheit von Git
Git wurde mit der Integrität des verwalteten Quellcodes als oberste Priorität entworfen. Der Inhalt der Dateien sowie die wahren Beziehungen zwischen Dateien und Verzeichnissen, Versionen, Tags und Commits, all diese Objekte im Git-Repository sind mit einem kryptographisch sicheren Hash-Algorithmus namens SHA1 gesichert. Dieser schützt den Code und die Änderungshistorie sowohl vor versehentlichen als auch böswilligen Änderungen und stellt sicher, dass die Historie vollständig nachvollziehbar ist.
Git ist ein De-facto-Standard
Git ist das am weitesten verbreitete Instrument seiner Art. Dies macht Git aus den folgenden Gründen attraktiv.
Sehr viele Entwickler haben bereits Git-Erfahrung, und ein beträchtlicher Anteil der Hochschulabsolventen hat möglicherweise nur mit Git Erfahrung. Während einige Organisationen die Lernkurve erklimmen müssen, wenn sie von einem anderen Versionskontrollsystem zu Git migrieren, müssen viele ihrer bestehenden und zukünftigen Entwickler nicht auf Git geschult werden.
Git ist ein sehr gut unterstütztes Open-Source-Projekt mit über einem Jahrzehnt solider Verwaltung. Die Projektbetreuer haben ein ausgewogenes Urteilsvermögen und eine ausgereifte Herangehensweise gezeigt, um die langfristigen Bedürfnisse der Benutzer mit regelmäßigen Releases zu erfüllen, die die Benutzerfreundlichkeit und Funktionalität verbessern. Die Qualität der Open-Source-Software lässt sich leicht überprüfen, und unzählige Unternehmen verlassen sich stark auf diese Qualität.
Schulungsbedarf bei Git
Eine häufig geäußerte Kritik an Git ist, dass sie schwer zu erlernen sein kann. Einige der Terminologie in Git wird für Neulinge neu sein und für Benutzer anderer Systeme kann die Git-Terminologie anders sein, z.B. hat revert in Git eine andere Bedeutung als in SVN oder CVS. Nichtsdestotrotz ist Git sehr leistungsfähig und bietet seinen Benutzern eine Menge Power. Zu lernen, diese Leistung zu nutzen, kann einige Zeit in Anspruch nehmen, aber wenn es einmal erlernt wurde, kann diese Leistung vom Team (siehe auch Team Seminare) genutzt werden, um die Entwicklungsgeschwindigkeit zu erhöhen. Zu Git passend findet sich eine [url=https://www.gfu.net/seminare-schulungen-kurse/testmanagement_sk92/git-einstieg-versionsverwaltung_s1664.html.]Git Schulung[/url].
Für die Teams, die aus einem nicht verteilten VCS kommen, mag es als eine gute Sache erscheinen, ein zentrales Repository zu haben, das sie nicht verlieren wollen. Doch obwohl Git als ein verteiltes Versionskontrollsystem (DVCS) konzipiert wurde, können Sie mit Git immer noch ein offizielles, kanonisches Repository haben, in dem alle Änderungen an der Software gespeichert werden müssen. Da mit Git das Repository jedes Entwicklers vollständig ist, muss seine Arbeit nicht durch die Verfügbarkeit und Leistung des "zentralen" Servers eingeschränkt werden. Bei Ausfällen oder wenn sie offline sind, können die Entwickler immer noch den vollständigen Projektverlauf einsehen. Da Git sowohl flexibel ist als auch verteilt wird, können Sie so arbeiten, wie Sie es gewohnt sind, aber die zusätzlichen Vorteile von Git nutzen, von denen Sie vielleicht nicht einmal merken, dass Sie sie vermissen.
Terminoly in Git
Branch
Ein Branch ist ein benannter Zeiger auf eine Übergabe. Das Auswählen eines Zweiges in der Git-Terminologie wird aufgerufen, um einen Zweig auszuchecken. Wenn Sie in einem bestimmten Zweig arbeiten, wird bei der Erstellung einer neuen Übertragung dieser Zeiger auf die neu erstellte Übertragung weitergeschaltet.
Jeder Commit kennt seine Eltern (Vorgänger). Nachfolger werden abgerufen, indem der Commit-Graph ausgehend von Zweigen oder anderen Referenzen, symbolischen Referenzen (z.B.: HEAD) oder expliziten Commit-Objekten durchlaufen wird. Auf diese Weise definiert ein Zweig seine eigene Linie von Nachfolgern im Gesamtversionsgraphen, der durch alle Commits im Repository gebildet wird.
Commit
Wenn Sie Ihre Änderungen in ein Repository "committen", wird ein neues Übertragungsobjekt im Git-Repository erstellt. Dieses Commit-Objekt identifiziert eindeutig eine neue Revision des Inhalts des Repositorys.
Diese Revision kann später abgerufen werden, z. B. wenn Sie den Quellcode einer älteren Version sehen möchten. Jedes Commit-Objekt enthält den Autor und den Committer. Dadurch ist es möglich, festzustellen, wer die Änderung vorgenommen hat. Der Autor und der Committer können verschiedene Personen sein. Der Autor hat die Änderung vorgenommen und der Committer hat die Änderung auf das Git-Repository angewendet. Dies ist bei Beiträgen zu Open-Source-Projekten üblich.
Head
HEAD ist ein symbolischer Verweis, der meistens auf den aktuell ausgecheckten Zweig verweist.
Manchmal zeigt der HEAD direkt auf ein Commit-Objekt, dies wird als losgelöster HEAD-Modus bezeichnet. In diesem Zustand wird bei der Erzeugung eines Commits kein Zweig verschoben.
Wenn Sie die Zweige wechseln, zeigt der HEAD-Zeiger auf den Zweigzeiger, der wiederum auf eine Übergabe zeigt. Wenn Sie eine bestimmte Übergabe auschecken, zeigt der HEAD-Zeiger direkt auf diese Übergabe.
Repository
Ein Repository enthält die Geschichte, die verschiedenen Versionen im Laufe der Zeit und alle verschiedenen Zweige und Tags. In Git ist jede Kopie des Repositorys ein vollständiges Repository. Wenn das Projektarchiv kein reines Projektarchiv ist, erlaubt es Ihnen, Revisionen in Ihren Arbeitsbaum auszuchecken und Änderungen durch das Erstellen neuer Übertragungen zu erfassen. Bare-Repositorys werden nur durch den Transport von Änderungen aus anderen Repositorys geändert.
In dieser Beschreibung wird der Begriff Repository verwendet, um von einem nicht bloßen Repository zu sprechen. Wenn von einem bloßen Repository die Rede ist, wird dies ausdrücklich erwähnt.
Tag
Ein Tag zeigt auf einen Commit, der eine Version des Git-Repositorys eindeutig identifiziert. Mit einem Tag können Sie einen benannten Punkt haben, zu dem Sie jederzeit zurückkehren können. Sie können zu jedem Punkt in einem Git-Repository zurückkehren, aber Tags machen es einfacher. Der Vorteil von Tags ist es, das Repository aus einem bestimmten Grund zu kennzeichnen, z.B. mit einer Veröffentlichung.
Zweige und Markierungen werden Zeiger genannt. Der Unterschied ist, dass sich Zweige beim Erstellen einer neuen Übergabe verschieben, während Markierungen immer auf dieselbe Übergabe zeigen. Tags können mit einem Zeitstempel und einer Nachricht versehen werden.
URL
Eine URL in Git bestimmt den Speicherort des Repositorys. Git unterscheidet zwischen fetchurl, um neue Daten von anderen Repositories zu erhalten, und pushurl, um Daten in ein anderes Repository zu schieben.
Technische Details eines Commit-Objekts
Dieses Commit-Objekt ist über einen Hash adressierbar ( SHA-1-Prüfsumme ). Dieser Hash wird basierend auf dem Inhalt der Dateien, dem Inhalt der Verzeichnisse, der vollständigen Historie bis zur neuen Übergabe, dem Committer, der Commit-Nachricht und verschiedenen anderen Faktoren berechnet.
Das bedeutet, dass Git sicher ist, Sie können eine Datei oder die Commit-Nachricht im Git-Repository nicht manipulieren, ohne dass Git bemerkt, dass der entsprechende Hash nicht mehr zum Inhalt passt.
Das Commit-Objekt verweist über ein Baumobjekt auf die einzelnen Dateien in dieser Übertragung. Die Dateien werden im Git-Repository als Blob-Objekte gespeichert und können von Git zur besseren Leistung und kompakteren Speicherung gepackt werden. Blobs werden über ihren SHA-1-Hash angesprochen.
Das Packen beinhaltet die Speicherung von Änderungen als Deltas, Komprimierung und Speicherung vieler Objekte in einer einzigen Pack-Datei. Pack-Dateien werden von einer oder mehreren Indexdateien begleitet, die den Zugriff auf einzelne Objekte, die in diesen Packs gespeichert sind, beschleunigen.