Archiv der Kategorie: Linux

Zugriff auf FTP-Server mit dynamischer IP

Um einen Linux-Server in Ihrem Netzwerk über FTP (File Transfer Protocol) mit Hilfe von Selfhost.de zu erreichen, müssen wir einige Schritte ausführen.

Schritt 1: Domain bei Selfhost.de registrieren

  1. Geh auf die Website von Selfhost.de (https://www.selfhost.de/) und erstell dir ein Konto, wenn du noch keins hast.
  2. Nach der Anmeldung geh zu „Domains“ oder einer ähnlichen Option auf der Website, um deine gewünschte Domain zu registrieren. Folge den Anweisungen auf der Website, um die Domain zu registrieren.
  3. Warte, bis die Domain erfolgreich registriert ist. Das kann einige Stunden oder länger dauern, je nachdem, wie schnell die DNS-Einträge aktualisiert werden.
  4. Stelle deinem Router die Anmeldedaten zur Verfügung, damit der die IP, unter der er mit dem Internet verbunden ist, mitteilen kann. Hier am Beispiel eines FRITZ!Box-Routers.

Schritt 2: Deinen Linux-Server vorbereiten

  1. Stell sicher, dass dein Linux-Server ordnungsgemäß eingerichtet und mit dem Internet verbunden ist.
  2. Installiere einen FTP-Server auf deinem Linux-Server, wenn das bisher nicht geschehen ist. vsftpd ist ein häufig verwendeter FTP-Server für Linux und kann in den meisten Linux-Distributionen über den Paketmanager installiert werden. Zum Beispiel, auf einem Debian-basierten System, verwende diesen Befehl:
sudo apt-get install vsftpd
  1. Konfiguriere den FTP-Server gemäß deinen Anforderungen. Du kannst die Konfigurationsdatei ändern, um den FTP-Zugriff auf die gewünschten Verzeichnisse und Benutzer zu beschränken.
sudo nano /etc/vsftpd.conf # Konfiguration
sudo systemctl enable vsftpd # für Autostart
sudo systemctl start vsftpd # jetzt starten
sudo systemctl status vsftpd # Status prüfen

Per Default kann man sich nun bereits über FTP und einem Linux-User lesend zum Server verbinden. Es versteht sich von selbst, dass man hierfür keinen Superuser nehmen sollte, sondern einen User mit extra konfigurierten Rechten. Hier ist eine gute Anleitung für das weitere Vorgehen bzgl. FTP-Server-Konfiguration.

Schritt 3: Portweiterleitung einrichten

Damit dein Linux-Server über das Internet erreichbar ist, musst du Portweiterleitungen auf deinem Router einrichten. Das ermöglicht den Zugriff auf den FTP-Server von außerhalb deines Netzwerks.

  1. Geh in das Webinterface deines Routers. Die IP-Adresse und Anmeldeinformationen deines Routers findest du normalerweise auf der Unterseite des Geräts oder in der Dokumentation.
  2. Suche den Bereich für Portweiterleitungen oder „Port Forwarding“ in den Router-Einstellungen.
  3. Erstelle eine Portweiterleitung für den FTP-Port (standardmäßig 21) auf die interne IP-Adresse deines Linux-Servers.

Nicht vergessen, das richtige Gerät auszuwählen.

Schritt 4: DDNS bei Selfhost.de einrichten

  1. Melde dich bei deinem Selfhost.de-Konto an.
  2. Geh zu den DNS-Einstellungen oder DDNS-Einstellungen auf der Selfhost.de-Website.
  3. Konfiguriere DDNS mit deiner registrierten Domain. Fülle die erforderlichen Informationen wie den Hostnamen und dein Passwort aus.

Schritt 5: FTP-Client verwenden

Jetzt kannst du deinen FTP-Client verwenden, um auf deinen Linux-Server zuzugreifen:

  1. Öffne deinen FTP-Client und gib die Domain ein, die du bei Selfhost.de registriert hast, als Hostnamen ein.
  2. Verwende deinen FTP-Benutzernamen und dein Passwort, um dich anzumelden.
  3. Du solltest jetzt in der Lage sein, Dateien zwischen deinem lokalen Computer und dem Linux-Server über FTP zu übertragen.

Bitte beachte, dass die Sicherheit deines Systems von entscheidender Bedeutung ist, wenn du FTP öffentlich zugänglich machst. Stelle sicher, dass du angemessene Sicherheitsvorkehrungen wie Verschlüsselung (FTP over TLS/SSL) und sichere Passwörter verwendest, um deinen Server zu schützen.

Überprüfen der Festplatte (SSD/HDD) unter Linux/Debian

Klar, ich helfe dir gerne dabei, die Festplatte (SSD/HDD) auf einem Linux-System (Debian) zu überprüfen.

  • S.M.A.R.T.-Überwachung (Self-Monitoring, Analysis, and Reporting Technology): Dies ist eine integrierte Technologie, die den Zustand einer Festplatte überwacht und auf potenzielle Probleme hinweist. Du kannst das smartctl-Befehlszeilenprogramm verwenden, um die S.M.A.R.T.-Informationen deiner Festplatte anzuzeigen. Falls es nicht bereits installiert ist, installiere es mit:
sudo apt update
sudo apt install smartmontools

Dann kannst du die S.M.A.R.T.-Informationen deiner Festplatte mit diesem Befehl überprüfen (ersetze /dev/sdX durch den tatsächlichen Pfad deiner Festplatte, z.B., /dev/sda):

sudo smartctl -t short /dev/sda # einen Test laufen lassen
sudo smartctl -a /dev/sda # Testergebnisse auslesen

Prüfe die Ergebnisse auf Fehler oder Warnungen.

  • Festplattentests: Um die Festplatte auf fehlerhafte Blöcke zu überprüfen, kannst du spezielle Tools wie badblocks verwenden. Beachte jedoch, dass dies zu Datenverlust führen kann, wenn Fehler gefunden werden. Verwende es daher mit Vorsicht. Installiere es, wenn es nicht bereits installiert ist:
sudo apt update
sudo apt install e2fsprogs # eine Reihe von nützlichen Dienstprogramme

Dann kannst du badblocks verwenden, um die Festplatte zu überprüfen:

sudo badblocks -sv /dev/sda
  • Festplatten- und Dateisystemintegrität überprüfen: Du kannst auch das Dateisystem auf Fehler überprüfen. Verwende fsck (Filesystem Consistency Check) für diese Aufgabe. Zum Beispiel:
sudo umount /dev/sda # Unmounte das Dateisystem zuerst
sudo fsck -f /dev/sda

Ersetze /dev/sdX durch den Pfad deiner Festplatte. (Natürlich nur, wenn die Festplatte nicht gerade in Gebrauch ist.)

Diese Schritte helfen dir, die Gesundheit und Integrität deiner Festplatte unter Linux/Debian zu überprüfen. Beachte, dass du diese Aufgaben am besten im Wartungsmodus durchführst, um Datenverlust zu vermeiden.

Debian/Linux – Wie erfolgt ein Stresstest?

Das Stressen eines Linux-Servers kann hilfreich sein, um seine Leistungsfähigkeit und Stabilität zu überprüfen. Es gibt verschiedene Werkzeuge und Ansätze, um einen Debian-Server zu stressen.

  • Stress-Test-Werkzeuge installieren: Zuerst müssen wir einige Stress-Test-Werkzeuge installieren.
sudo apt update
sudo apt install stress

Das „stress“-Werkzeug wird verwendet, um den Server zu stressen.

  • CPU-Test durchführen: Wir können die CPU des Servers stressen, indem wir die Anzahl der CPU-Kerne auf komplette Auslastung erhöhen.
stress --cpu 4 # 4 steht für die Anzahl der CPU-Kerne; eventuell anpassen

Dies wird die CPU für eine bestimmte Anzahl von Threads voll auslasten. Mithilfe von top können wir in einer zweiten Konsole sehen, wie der Rechner komplett auf Anschlag fährt. Beenden wir den Test mit Ctrl+C, wenn wir fertig sind.

  • RAM-Test durchführen: Um den Arbeitsspeicher zu stressen, verwenden Sie den folgenden Befehl:
stress --vm 4 --vm-bytes 256M

Dies wird den Arbeitsspeicher mit 4 Threads stressen, wobei jeder 256 Megabyte RAM beansprucht.

  • I/O-Test durchführen: Um das Festplatten-I/O zu stressen, verwenden Sie:
stress --io 4

Dies wird das Festplatten-I/O mit 4 Threads stressen. Ändern wir die Thread-Anzahl nach Bedarf.

  • Temperatur und Ressourcen überwachen: Während des Stress-Tests sollten wir Temperatur und Ressourcennutzung überwachen, um sicherzustellen, dass der Server nicht überhitzt und keine kritischen Ressourcen erschöpft sind. Wir können Werkzeuge wie sensors oder top verwenden.
  • Beenden des Stress-Tests: Um den Stress-Test zu beenden, drücken wir Ctrl+C im Terminal.

Bitte beachten, dass das Stressen eines Servers potenziell seine Leistung beeinträchtigen kann und zu einer vorübergehenden Unzugänglichkeit führen kann. Führen wir solche Tests daher nicht auf Produktions- oder wichtigen Servern durch, sondern auf dedizierten Testsystemen (oder auf Servern, die erst noch zu Produktionsservern gemacht werden.)

Wie synchronisiere ich ein Projekt mit einem schon existierendem Repository in GitHub?

Wer erst nachträglich auf die Idee kommt, den eigenen Entwicklungsserver mit einem Produktionsserver per Git und GitHub zu synchronisieren, steckt vor dem Problem, wie man eine Verbindung zu GitHub herstellt und einen erstmaligen Abgleich der Dateien herstellt. Danach kann und sollte ein Deployment dann nur noch per git erfolgen.

Wie immer ist es einfach, wenn man weiß, wie es geht, oder welche Fragen man stellen muss.

Problembeschreibung

Problem: ein Projekt (auf Produktion), das bisher nur mit FTP deployt wurde, soll nachträglich nur noch mit einem GitHub Repository ohne FTP synchronisiert werden.

SSH-Schlüssel bei GitHub hinterlegen

Da es sich aller Wahrscheinlichkeit nach um ein privates Projekt handelt, muss sich der Produktionsserver (=Ziel) gegenüber GitHub authentifizieren. Dazu muss man einen öffentlichen Schlüssel erzeugen und bei GitHub hinterlegen. Erklärt habe ich das bereits hier (für Windows) und hier (für Linux).

ls -al ~/.ssh # testen, ob schon Keys vorhanden sind
mkdir ~/.ssh # wenn nicht, Ordner anlegen
cd ~/.ssh
ssh-keygen -t rsa -b 4096 -C "<BESCHREIBUNG>"
ls -la

Danach muss git wissen, wo es die SSH-Schlüssel findet.

nano ~/.ssh/config

Der einfachste und funktionsfähige Inhalt wäre folgender:

# Private github account: 1manfactory
Host github-private
HostName github.com
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yes

Wir müssen GitHub als bekannten Host hinzufügen:

ssh-keyscan github.com >> ~/.ssh/known_hosts

Ich authentifiziere mich als git@github-private bei GitHub.

ssh -T git@github-private

Das git Repository auf Produktion anlegen und mit dem remote Repository verbinden

Navigieren Sie zum Verzeichnis Ihres lokalen Projekts auf dem Produktionsserver und führen Sie folgende Befehle aus.

cd <PROJEKTVERZEICHNIS>
git init
git config -l
git remote add origin git@github-private:<USER>/<REPOSITORY>.git
git remote -v
git pull origin main
git checkout main -f
git branch --set-upstream-to origin/main

Ich erkläre die einzelnen Schritte.

git init ist ein Befehl, der ein neues Git-Repository in einem lokalen Verzeichnis erstellt. Er legt einen versteckten Ordner namens .git an, der die Repository-Daten enthält. Er macht das Verzeichnis bereit für die Versionskontrolle mit Git.

git config -l ist ein Befehl, der alle Git-Konfigurationsoptionen anzeigt, die für das aktuelle Repository oder den aktuellen Benutzer gesetzt sind. Er liest die Werte aus den Dateien .git/config, ~/.gitconfig und /etc/gitconfig. Er kann nützlich sein, um die Einstellungen zu überprüfen oder zu ändern.

git remote add origin ist ein Befehl, der einen Remote-Namen namens origin zu einem lokalen Repository hinzufügt. Er verbindet das lokale Repository mit einem Remote-Repository, das an den Befehl angehängt wird. Er ermöglicht das Hochladen und Herunterladen von Änderungen zwischen den Repositories.

git remote -v zeigt die Liste der Remote-Namen und ihre URLs an. Er hilft zu überprüfen, ob die Remote-Verbindungen korrekt sind.

git pull origin main ist ein Befehl, der den lokalen Branch main mit dem Remote-Branch main von origin aktualisiert. Er lädt zuerst alle Änderungen vom Remote-Repository herunter und führt dann einen Merge oder einen Rebase aus. Er bringt das lokale Repository auf den neuesten Stand.

git branch --set-upstream-to origin/main ist ein Befehl, der den aktuellen lokalen Branch mit dem Remote-Branch main von origin verknüpft. Er legt fest, welcher Remote-Branch als Standard für das Pushen und Pullen verwendet wird. Er erleichtert die Synchronisation zwischen den Branches.

Als Ergebnis sollte jetzt der Produktionsserver auf demselben Stand sein wie das GitHub-Repository (und damit auch wie der Entwicklungsserver).

Das zukünftige Deployment

Ab jetzt können wir den Weg über git pull oder git fetch && git merge gehen, um Änderungen aus dem remote Repository bei GitHub zu übernehmen.

Die schnelle Methode ‘git pull’

git pull

git pull ist ein Befehl, der den aktuellen lokalen Branch mit dem entsprechenden Remote-Branch aktualisiert. Er entspricht einem git fetch gefolgt von einem git merge oder einem git rebase. Er benötigt einen Remote-Namen und einen Branch-Namen oder eine Verknüpfung zwischen den Branches.

Die vorsichtigere Methode mit ‘get fetch’

git fetch origin
git log origin/main ^main
git diff main origin/main
git merge

git fetch origin ist ein Befehl, der alle Änderungen vom Remote-Repository origin herunterlädt. Er aktualisiert die lokalen Referenzen zu den Remote-Branches, aber nicht die lokalen Branches. Er ermöglicht es, die Differenzen zwischen den Branches zu sehen oder einen Merge oder einen Rebase auszuführen.

git log origin/main ^main ist ein Befehl, der die Commit-Historie vom Remote-Branch origin/main anzeigt, die nicht im lokalen Branch main enthalten ist. Er hilft, zu sehen, welche Änderungen noch nicht synchronisiert sind.

Der Befehl git diff main origin/main zeigt die Unterschiede zwischen dem lokalen Zweig main und dem entfernten Zweig origin/main an². Er kann verwendet werden, um zu sehen, welche Änderungen Sie noch nicht mit dem entfernten Repository synchronisiert haben.

Git und GitHub für Windows mit Sourcetree, Teil 3: Branches, Pull Requests und Fetch

Das Thema Branches ist sehr wichtig für die Arbeit mit GitHub. Im Grunde kommt man nicht an ihnen vorbei, spätestens wenn man nicht mehr allein an einem Projekt arbeitet.

Was sind Branches?

In Git sind Branches (dt. Zweige) Versionen des Projekts, die sich inhaltlich voneinander unterscheiden und dabei gleichzeitig parallel existieren können.

Branches sind eine wichtige Funktion in Git, da sie es Entwicklern ermöglichen, verschiedene Ideen oder Experimente gleichzeitig auszuprobieren, ohne die ursprüngliche Version des Projekts zu beeinträchtigen. Zum Beispiel kann man einen neuen Branch erstellen, um eine neue Funktion auszuprobieren, während der Haupt-Branch stabil bleibt. Wenn die neue Funktion erfolgreich getestet wurde, kann sie in den Haupt-Branch übernommen („gemerged“) werden.

Git ermöglicht auch, zwischen Branches zu wechseln und zu arbeiten, wodurch Entwickler effizienter arbeiten können, ohne dass sie separate Arbeitskopien erstellen müssen.

Das Wechseln zwischen Branches ist einfach und schnell, sodass Entwickler problemlos zwischen verschiedenen Versionen ihres Projekts navigieren können.

Wir legen einen neuen Branch an

  1. Öffnen Sie Ihr Repository in Sourcetree.
  2. Klicken Sie auf den Button „Branch“ in der oberen Menüleiste.
  3. Klicken Sie auf den Reiter „New Branch“ im neuen Fenster.
  4. Geben Sie einen Namen für Ihren neuen Branch ein und wählen Sie den Branch aus, von dem Sie den neuen Branch ableiten möchten. Standardmäßig wird der neue Branch von dem aktuell ausgewählten Branch (hier: main) abgeleitet.
  5. Klicken Sie auf den Button „Create Branch“.

Ich nenne den neuen Branch „new_feature“. Allerdings werden wir kein neues Feature einführen, sondern lediglich an der schon bekannten Datei „README.md“ etwas ändern.

Fortan wollen wir also im „new_feature“-Branch arbeiten. In unserem Repository wird aber weiterhin das Projekt in seiner ursprünglichen Version verbleiben und parallel existieren.

Mit einem Doppelklick auf der linken Seite auf den Namen der Branch springen wir zwischen „main“ und „new_feature“ hin und her.

Wir fügen jetzt in unserer bekannten Datei „README.md“ eine neue Zeile, genauer eine neue Überschrift hinzu. Außerdem ist mir gerade aufgefallen, dass ich „turotial“ statt „tutorial“ geschrieben habe. Das wird auch korrigiert.

Nach dem Speichern wechseln wir wieder zu Sourcetree und sehen nach wenigen Sekunden Wartezeit erwartungsgemäß unsere Datei wieder im Status „Unstaged“. Rechts oben erkennen wir die vorgenommenen Änderungen.

Wie bereits durchexerziert, schieben wir die Datei in den „Staged“ Bereich und führen anschließend ein Commit durch.

Nun sehen wir einen veränderte History-Bereich:

In dem neuen Branch wurden die Änderungen übernommen. Klicken wir nun wieder auf den ursprünglichen Branch, sehen wir noch den alten, ursprünglichen Stand der Datei.

Jetzt sorgen wir mit „Push“ dafür, dass die veränderte Datei bei GitHub landet. Im aufgehenden Fenster nehmen Sie bitte folgende Anpassungen vor:

Und wieder ist eine kleine Änderung im History-Bereich zu sehen.

Schauen wir jetzt in GitHub nach, was passiert ist. Sie wechseln jetzt in den Status, und damit in die Perspektive, des Administrators. Sie sind also jetzt eine andere Person als die, die die Änderungen vorgenommen hat.

GitHub weist uns darauf hin, dass ein neuer Branch angelegt worden ist und dass in diesen Branch neue Dateien (in unserem Falle nur eine) gepusht wurden.

Da wir uns aber noch im Hauptbranch „main“ befinden, sind die Änderungen noch nicht zu sehen – was ja Sinn der Aktion war. Denn noch wissen wir nicht, ob die Änderungen fehlerfrei sind und bei den anderen (spekulativen) Administratoren im Projekt Akzeptanz finden.

Wir zeigen jetzt den Branch „new_feature“ an. Dazu drücken wir den Dropdown-Button mit der Aufschrift „main“ und wechseln auf „new_feature“

Wir sehen jetzt den neuen Branch „new_feature“

Dieser Branch hat jetzt (auch wieder wie erwartet) unsere Änderungen und befindet sich „1 commit ahead of main“. Was bedeutet das?

Der aktuelle Branch hat einen Commit mehr als der Branch „main“. Die Änderungen im neuen Feature-Branch wurden noch nicht in den „main“-Branch übertragen (=gemerged). Auch das ist ein schlüssiges, gewolltes Verhalten von git bzw. GitHub.

Compare & pull request

Sehen Sie den Button mit der Aufschrift “Compare & pull request”?

„Compare“ und „Pull Request“ sind Funktionen in Git und GitHub, die es Entwicklern ermöglichen, Änderungen an einem Repository vorzuschlagen und sie in den Hauptzweig (z.B. „main“ oder „master“) zu integrieren.

„Compare” ermöglicht es, den Unterschied zwischen zwei Branches aufzuzeigen, indem Änderungen, die gemacht wurden, gegenübergestellt werden. Dadurch können Entwickler sehen, welche Dateien und Zeilen geändert wurden und welche Auswirkungen die Änderungen haben werden.

Ein „Pull Request“ ist eine Anfrage an den Repository-Administrator (in diesem Falle ausschließlich an uns selbst), um Änderungen in den Hauptzweig des Repositorys zu übernehmen. Der Administrator kann dann die Änderungen überprüfen, Kommentare dazu abgeben und sie gegebenenfalls genehmigen und zusammenführen oder auch ablehnen.

Nach Klick auf den Button „Compare & pull request“ gibt es folgendes Fenster in GitHub.

Wir sehen praktischerweise schon den Kommentar, den wir beim Commit der Änderungen angegeben haben. Es gibt aber auch die Möglichkeit, einen längeren, erkenntnisreichen Kommentar zu hinterlassen.

Wenn wir etwas nach unten scrollen, sehen wir die erfolgten Änderungen im Detail, wie wir es schon in Sourcetree kennenlernen durften.

Mit „Create pull request“ werden wir nun die Anfrage an den Administrator (auch wenn wir das selbst sind) stellen, unseren neuen Code in dem Branch „new_feature“ zu kontrollieren und bei Akzeptanz, in den Haupt-Branch „main“ zu übernehmen.

Schauen wir, was passiert, wer wir den Knopf drücken. Es öffnet sich ein neues Fenster im Browser.

Die Änderungen akzeptieren

Wir sehen oben die Überschrift des Commits, eine Beschreibung hatten wir nicht angegeben. Interessanterweise kann GitHub schon feststellen, dass es voraussichtlich keine Konflikte beim Zusammenführen der README.md-Datei auf dem Hauptbranch geben wird.

Bevor wir den Request jetzt final akzeptieren, scrollen wir noch kurz nach unten.

Hier könnten wir, wenn wir wollten, den Request ablehnen (und vorher noch einen Kommentar dazu hinterlassen.)

Aber wir haben uns ja dazu entschieden, den Request zu akzeptieren, also drücken wir beherzt auf „Merge pull request“.

Nach einer kleinen Zwischenfrage, auf die wir einen kleinen Kommentar (z.B. einen Dank an den fleißigen Programmierer) hinterlassen können, drücken wir jetzt aber wirklich final auf „Confirm merge“.

So sieht dann das Ergebnis aus:

Der Pull request wurde erfolgreich eingebunden und wurde jetzt geschlossen. Der Administrator hat nun noch die Gelegenheit den „new_feature“-Branch zu löschen oder nicht.

Es hängt von den individuellen Projektanforderungen und -richtlinien ab, ob er dies tut. Einige Teams bevorzugen das Löschen des Feature-Branches, um eine saubere und übersichtliche Branch-Historie zu erhalten, während andere Teams den Feature-Branch behalten möchten, um mögliche zukünftige Probleme leichter zu identifizieren und zu debuggen.

Es gibt jedoch auch Kompromisslösungen, wie zum Beispiel das Umbenennen des Feature-Branches in einen entsprechenden Namen, um anzuzeigen, dass er bereits gemerged wurde. In jedem Fall ist es wichtig, klare Richtlinien für das Branching-Verhalten im Team zu definieren und sicherzustellen, dass alle Teammitglieder diese Richtlinien verstehen und befolgen.

So sieht jetzt der Hauptbranch aus. Die Änderungen wurden komplett übernommen.

Die Änderungen im lokalen Repository – Pull oder Fetch

Damit jetzt alle am Projekt Beteiligten wieder auf den gleichen Stand der Entwicklung kommen – z.B. am Beginn eines neuen Arbeitstages, müssen sie die aktuellen Änderungen aus dem entfernten (remote) Repository auf GitHub übernehmen. Das schließt übrigens auch den Einreicher des „Pull requests“ selbst mit ein, denn er weiß ja noch nicht, dass seine Änderungen akzeptiert worden sind.

Um das zu erreichen, gibt es die Befehle „pull“ und „fetch“, die beide dafür da sind, Änderungen aus dem entfernten Repository zu übernehmen, sich aber in einem wichtigen Punkt unterscheiden.

Der Befehl „fetch” ruft alle Änderungen ab, die in einem Remote-Repository vorgenommen wurden, ohne diese in das lokale Repository zu integrieren. Dadurch können Sie sehen, welche Änderungen in dem Remote-Repository vorliegen, bevor Sie entscheiden, ob Sie sie zusammenführen möchten oder nicht.

Im Gegensatz zum Befehl „pull“ führt „fetch“ keine automatische Zusammenführung durch. Stattdessen müssen Sie entscheiden, ob Sie die Änderungen in Ihr lokales Repository integrieren möchten. Wir werden das jetzt mal machen.

Nach Klick auf „Fetch“ in der oberen Menüleiste erhalten wir drei Optionen zur Auswahl:

„Fetch from all remotes“ in Git bedeutet, dass alle Remote-Repositories, die mit dem lokalen Repository verbunden sind, nach Aktualisierungen durchsucht werden.

“Prune tracking branches no longer present on remote(s)?” entfernt die lokalen Tracking-Branches irreversible, die nicht mehr auf dem Remote-Repository vorhanden sind.

„Fetch all tags“ lädt alle Tags aus dem Repository herunter. Ein Tag ist ein Name, der einem bestimmten Commit zugewiesen wird, um ihn zu markieren. Es kann nützlich sein, alle Tags herunterzuladen, um sicherzustellen, dass Sie alle Informationen zu bestimmten Commits haben, einschließlich Informationen zu veröffentlichten Versionen oder Meilensteinen.

Ich belasse es fürs Erste bei den Default-Einstellungen.

Als Ergebnis erhalten wir … nichts, oder zumindest keine Änderungen. Woran liegt das? Das ist in unserem Falle leicht zu erklären, da wir ja die Einzigen sind, die Änderungen vorgeschlagen haben. Dementsprechend werden uns keine Differenzen aus anderen Pull/Merge requests angezeigt.

Wir können daher beruhigt „Pull“ in der Menüzeile drücken, um den Abgleich mit dem remote Repository abzuschließen

Nun haben wir vier Optionen zur Auswahl.

Mit „Commit merged changes immediately“ wird Git automatisch einen neuen Commit erstellen, der die zusammengeführten Änderungen beim Zusammenführen von Branches enthält. Wenn Sie das nicht möchten, bspw. aus Kontrollgründen, müssen Sie das später von Hand machen.

„Include messages from commits merged in merge commit“. Wenn diese Option ausgewählt ist, werden die Commit-Messages der zusammengeführten Commits in den Merge-Commit übernommen. Ich würde aus Gründen der Übersichtlichkeit darauf verzichten.

„Create a new commit even if fast-forward is possible?“ lassen wir fürs Erste deaktiviert, ansonsten könnten wir die neuen Commits aus dem Merge nicht mehr rückgängig machen.

„Rebase instead of merge“ – dieser Punkt dient dazu, die komplette Commit-Historie in einem linearen Verlauf zusammenzuführen. Das kann übersichtlicher sein, kann aber dazu führen, dass Informationen verloren gehen. Bei neuen Projekten sollte man sich einmalig festlegen, welcher der beiden Methoden genutzt wird. Es sollte tunlichst darauf geachtet werden, beide Methoden nicht zu vermischen. Ich lasse dieses Feld deaktiviert, da ich immer der Merge-Methode den Vorzug vor Rebase gebe.

Ich setze jetzt lediglich den Haken bei „Commit merged changes immediatly“, da ich davon ausgehe, dass beim Merge in GitHub alles richtig war.

Wie Sie sehen, hat sich nichts großartig getan, außer dass die kleine „2“ verschwunden ist, denn jetzt haben wir eigentlich unsere zuvor selbst erstellten Änderungen „gepullt“ haben. Das Ergebnis wäre ein anderes, wenn wir auch Änderungen anderer Personen übernommen hätten. Das werden wir im nächsten Kapitel sehen.

Zusammenfassung: Wir wissen nun, wie wir Änderungen über einen neuen Branch zu GitHub einspielen, wie wir diese Änderungen in den Hauptbranch einfügen und wie wir externe Änderungen im Code in unser Repository übernehmen können.