ubuntuusers.de

😉 Man kann's ja der Link-Beschreibung zu GitHub hinzufügen.

Ich würde noch folgende Konfigurationen empfehlen

Wenn abwechselnd auf Linux/Mac oder Windows gearbeitet wird empfiehlt es sich, folgende Konfigurationen hinzuzufügen, um Zeilenenden zuverlässig zu handhaben

# Für Linux/Mac
git config --global core.autocrlf input

# Für Windows
git config --global core.autocrlf true

Git verwendet als Standard Editor vim oder vi. Wer einen anderen Editor möchte kann folgende Konfiguration hinzufügen:

# Für VSCode
git config --global core.editor "code --wait"

# Für nvim
git config --global core.editor nvim

# Folgender Befehl öffnet den Editor
git config --global -e

Weiterhin empfiehlt es sich, als Standard Branch "main" anstatt "master" zu verwenden (siehe: Stellungnahme von Github). Um sicherzustellen, dass in neuen Repositories "main" verwendet wird sollte man folgende Konfiguration hinzufügen

git config --global init.defaultBranch main

Kann man das so ins Wiki übernehmen?

Eventuell noch eine weitere Anmerkung: um eine Änderung rückgängig zu machen verwendet man nicht mehr checkout sondern restore

Änderungen, die nicht zum Commit vorgemerkt sind:
  (benutzen Sie "git add <Datei>...", um die Änderungen zum Commit vorzumerken)
  (benutzen Sie "git restore <Datei>...", um die Änderungen im Arbeitsverzeichnis zu verwerfen)

Ist mir gerade aufgefallen, weil in einem Tutorial in der Ausgabe noch "checkout" steht, bei mir aber "restore" ausgegeben wird. Habe das auch schon an anderer Stelle gelesen, dass der "offizielle" Weg jetzt "restore" ist, auch wenn "checkout" nach wie vor funktioniert, um Unklarheiten zu vermeiden.

burli schrieb:

[...] Kann man das so ins Wiki übernehmen?

Du kannst das so gerne in den Abschnitt „Einrichtung“ übernehmen. Evtl. empfiehlt sich auch ein separater Abschnitt zur Konfiguration mit Anleitung, wie man sie manuell bearbeitet.

burli schrieb:

Eventuell noch eine weitere Anmerkung: um eine Änderung rückgängig zu machen verwendet man nicht mehr checkout sondern restore [...]

Ändere das gerne. Der Befehl wäre ja dann git restore . äquivalent.

Hab die Änderungen eingefügt.

Generell finde ich die Seite aber noch nicht wirklich brauchbar, da ein wichtiges Element, die Staging Area, bisher noch nie erwähnt wurde.

.gitignore wird eigentlich gar nicht erklärt.

Mir ist klar, dass die Seite kein vollständiges Tutorial sein soll, aber die wichtigsten Dinge sollten zumindest richtig erklärt werden.

Wenn es gewünscht ist kann ich noch ein paar Änderungen vornehmen.

burli schrieb:

[...] Wenn es gewünscht ist kann ich noch ein paar Änderungen vornehmen.

Kannst Du machen. Anmerkung zu Deinen Änderungen: Du hast jetzt den Befehl restore nur im Zusammenhang mit für ein Commit markierten Dateien, also der Option --staged, erwähnt. Der Befehl checkout -f setzt aber den ganzen Projektbaum auf den Index zurück, egal ob die geänderten Dateien markiert, oder überhaupt Git bekannt sind.

karzer schrieb:

Kannst Du machen. Anmerkung zu Deinen Änderungen: Du hast jetzt den Befehl restore nur im Zusammenhang mit für ein Commit markierten Dateien, also der Option --staged, erwähnt. Der Befehl checkout -f setzt aber den ganzen Projektbaum auf den Index zurück, egal ob die geänderten Dateien markiert, oder überhaupt Git bekannt sind.

Danke für den Hinweis. Ich überarbeite das später nochmal.

Hab in der Zwischenzeit noch eine Beschreibung für .gitignore eingefügt. Ich fand das so nichtssagend. Außerdem hab ich auf Github ein Repo mit etlichen Beispielen für verschiedene Sprachen gefunden und verlinkt.

Hab mal ein wenig nachgelesen. git checkout -f und git reset --hard sind eigentlich identisch. Und da checkout eigentlich zum Wechseln von Branches gedacht ist sollte man ihn vielleicht nicht für so eine Funktion "missbrauchen".

Eigentlich sollte man sogar den Befehl git reset --hard HEAD verwenden. git checkout -f ist redundant.

burli schrieb:

Hab mal ein wenig nachgelesen. git checkout -f und git reset --hard sind eigentlich identisch. Und da checkout eigentlich zum Wechseln von Branches gedacht ist sollte man ihn vielleicht nicht für so eine Funktion "missbrauchen". [...]

Hmmm, theoretisch beschreibt das Zurücksetzen auf den letzten verzeichneten Stand das Wechseln auf den derzeit aktiven Ast. Aber wenn die Entwickler davon abraten, soll es so sein. Ich habe noch ein paar kleinere Schönheitskorrekturen vorgenommen, sieht ansonsten gut aus. Bitte 😬 immer auf die korrekte Nutzung des Bindestriches bei zusammengesetzten Hauptwörtern achten! Ich habe das in meiner „Laufbahn“ dermaßen oft korrigieren müssen, dass es mir langsam zum Hals heraushängt.

Sorry für die Fehler. Ich Versuche eigentlich schon, möglichst fehlerfrei zu schreiben. Auf die Bindestriche habe ich allerdings nicht geachtet.

Die Konsolenausgabe bei git add -h und besonders bei git rm -h hab ich eigentlich mit Absicht dazu geschrieben. Aber wenn das nicht gewünscht ist kann man es weg lassen.

Ich werde bei Gelegenheit vielleicht noch ein paar andere Änderungen machen. Ich tauche gerade tiefer in das Thema Git ein.