Was ist Git?

Ein verteiltes Versionsverwaltungssystem, das die Änderungsgeschichte von Dateien aufzeichnet und verwaltet. Im Arbeitsverzeichnis bearbeitete Änderungen werden mit git add in der Staging Area registriert, mit git commit im lokalen Repository aufgezeichnet und mit git push an ein Remote-Repository wie GitHub gesendet. Mit Branches lässt sich parallel entwickeln, und git merge führt sie zusammen. Neben Quellcode verwaltet man damit auch RTL, Verifikations-Testbenches, Skripte und Ähnliches.

Japanische Bezeichnung: Git

„Git“ kommt in 5 Übungsfragen aus 2 Themen vor, z. B. Grundlagen von Linux und der Kommandozeile, Softwareentwicklung und Projektmanagement.

Fachgebiet: Grundlagen von Linux und der Kommandozeile

Die drei Orte

Git unterscheidet das Arbeitsverzeichnis, in dem Dateien bearbeitet werden, die Staging Area (den Index), die die Änderungen für den nächsten Commit enthält, und das Repository (das Verzeichnis .git), das die Commit-Historie speichert. git status zeigt die Unterschiede zwischen diesen dreien; git diff zeigt den Unterschied zwischen Arbeitsverzeichnis und Staging Area, git diff --staged den zwischen Staging Area und letztem Commit.

Branches und Remotes

Ein Branch ist ein Name für eine Abzweigung in der Commit-Historie; damit lassen sich neue Funktionen oder Korrekturen entwickeln, ohne den Hauptbranch zu beeinflussen. git clone kopiert ein Remote-Repository lokal, git pull holt neue Commits aus dem Remote-Repository, und git push sendet die eigenen Commits. Werden Branches zusammengeführt, die dieselbe Stelle unterschiedlich geändert haben, entsteht ein Konflikt, den ein Mensch auflösen muss.

Was nicht versioniert wird

Dateien, die bei Builds und Simulationen entstehen, Logs, große Wellenformdaten und Ähnliches trägt man in .gitignore ein, um sie von der Verfolgung auszuschließen. Eine einmal committete Datei bleibt verfolgt, auch wenn sie in .gitignore steht, daher nimmt man sie mit git rm --cached heraus. Ein versehentlich committetes Passwort oder ein Schlüssel bleibt in der Historie erhalten; wichtig ist daher die Gewohnheit, den Inhalt vor dem Commit mit git status und git diff zu prüfen.

Jetzt üben: Fragen zu Git

Nach dem Bearbeiten der mit Git verwalteten Datei main.c wurde nur „git commit -m "fix"“ ausgeführt; es erschien „no changes added to commit“, und nichts wurde committet. Was ist der Grund?

  1. AVor dem Commit müssen die Änderungen mit git push an das gemeinsame Repository gesendet werden
  2. BÄnderungen, die in einen Commit aufgenommen werden sollen, müssen zuerst mit git add in der Staging Area registriert werden
  3. CGit committet beim Speichern einer Datei automatisch, daher muss git commit nicht ausgeführt werden
Antwort und Erläuterung anzeigen

Antwort: B. Änderungen, die in einen Commit aufgenommen werden sollen, müssen zuerst mit git add in der Staging Area registriert werden

In Git werden von den im Arbeitsverzeichnis bearbeiteten Änderungen nur diejenigen beim nächsten git commit aufgezeichnet, die mit git add in der Staging Area (dem Index) registriert wurden. Dieser zweistufige Mechanismus erlaubt es, aus mehreren Änderungen nur die zusammengehörigen auszuwählen und zu einem Commit zu machen. git status zeigt, welche Änderungen gestaged sind. Es gibt außerdem git commit -a, das alle Änderungen an verfolgten Dateien auf einmal vormerkt und committet.

In Git wurde git commit ausgeführt, doch im vom Team gemeinsam genutzten GitHub-Repository erscheint der Commit noch nicht. Was ist der Grund?

  1. Agit commit registriert Änderungen nur in der Staging Area; zum Aufzeichnen ist git add nötig
  2. BUm committete Änderungen an das gemeinsame Repository zu senden, muss git pull ausgeführt werden
  3. Cgit commit zeichnet im lokalen Repository auf; um an das Remote-Repository zu senden, ist git push nötig
Antwort und Erläuterung anzeigen

Antwort: C. git commit zeichnet im lokalen Repository auf; um an das Remote-Repository zu senden, ist git push nötig

Git ist ein verteiltes Versionsverwaltungssystem, bei dem jeder Entwickler das gesamte Repository lokal hat, und git commit zeichnet Änderungen in diesem lokalen Repository auf. Um sie an ein Remote-Repository wie GitHub zu senden, führt man git push aus; umgekehrt holt git pull (oder git fetch und git merge) neue Commits aus dem Remote-Repository in das lokale. Deshalb kann man auch ohne Netzwerkverbindung committen und später gesammelt pushen. Hat jemand anderes zuerst gepusht, wird man unter Umständen aufgefordert, zuerst dessen Änderungen zu übernehmen.

Häufige Fragen

Was ist der Unterschied zwischen Git und GitHub?

Git ist die Versionsverwaltungssoftware selbst, die auf dem eigenen Computer läuft. GitHub ist ein Webdienst, der Git-Repositorys hostet und Funktionen wie Reviews über Pull Requests und Issue-Verwaltung ergänzt. Es gibt ähnliche Dienste wie GitLab sowie Server im eigenen Unternehmen, und Git selbst lässt sich mit jedem davon verwenden.

Wie macht man den letzten Commit rückgängig?

Wurde er noch nicht gepusht, lässt sich der letzte Commit mit git commit --amend korrigieren oder mit git reset rückgängig machen. Bei einem bereits gepushten und geteilten Commit ist git revert sicherer, das die rückgängig machende Änderung als neuen Commit hinzufügt, damit es keine Widersprüche zu den Historien anderer gibt.

„Git“ in den Erläuterungen

Fragen mit „Git“ (5)

  1. Nach dem Bearbeiten der mit Git verwalteten Datei main.c wurde nur „git commit -m "fix"“ ausgeführt; es erschien „no changes added to commit“, und nichts wurde committet. Was ist der Grund?
  2. In Git wurde git commit ausgeführt, doch im vom Team gemeinsam genutzten GitHub-Repository erscheint der Commit noch nicht. Was ist der Grund?
  3. In der .gitignore eines mit Git verwalteten Projekts wurde „build/“ eingetragen, doch Änderungen an der früher committeten Datei build/out.log erscheinen weiterhin in git status. Was ist der Grund?
  4. In Git haben zwei Entwickler auf verschiedenen Branches dieselbe Zeile derselben Datei geändert, und dann wurde ein Branch in den anderen gemergt. Was geschieht dabei?
  5. Nach einer Firmware-Version, die bekanntermaßen korrekt funktioniert, gibt es 1000 Commits, und der neueste Commit enthält einen Fehler. Der Fehler wurde durch einen einzigen Commit eingeführt und tritt in jedem späteren Commit auf. Wie oft muss die Firmware höchstens gebaut und getestet werden, wenn der verursachende Commit wie mit git bisect durch binäre Suche ermittelt wird?

Verwandte Begriffe

Binäre Suche (Binary Search) cron Ein-/Ausgabeumleitung grep Hardlink Inode Pipe (|) Regulärer Ausdruck (Regex) Shell SSH

Zur Glossarübersicht