Show Menu
Cheatography
  1. Home >
  2. Programming >

Git und GitHub Cheat Sheet (DRAFT) by

Git und GitHub (Udemy Kurs Git Komplettkurs: Vom Anfänger zum Profi (inkl. GitHub))

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Allgemeine Befehle

pwd
in welchem Ordner man sich befindet
ls
Ordner­inhalt ausgeben
ls -a
um auch versteckte Ordner anzugeben
cd Ordner­name/
change directory - Ordner wechseln
cd ..
geht eine Ebene nach oben (Ordner)
mkdir Name
erstellt einen neuen Ordner
touch datei.txt
Datei erstellen
rm datei.txt
Datei löschen
mv dateii­i.txt datei.txt
Datei umbenennen dateii­i-txt -> datei.txt
mv datei.txt ../
Auch möglich: mv datei.txt ../d.txt
verschiebt die Datei in den Desktop
verschoben und umbenannt
cp datei.txt d.txt
erstellt Kopie der Datei
clear
Konsole leeren
cat datei.txt
gibt die Datei aus

neues Repository anlegen

git init
neues Repository im aktuellen Verzei­chnis
im Untero­rdner .git gespei­chert
ist eventuell ein verste­ckter Ordner
git status
zeigt, welche Dateien geändert wurden

Commit wieder­her­stellen

git checkout <commit hash>
stellt Zustand von einem Commit wieder her
git checkout master
springt zurück zum master (stellt den zuletzt gespei­cherten Zustand in dem repository wieder her)
Wird benutzt, um sich einen älteren Zustand anzusc­hauen (obwohl man weiß, wie der Code weiter verarb­eitet wurde)

Reposi­tor­y-H­istory ausgeben

git log
zeigt Commit­-Hi­storie
git log -p
zeigt mehr Details in der Commit­-Hi­storie (was hat sich geändert)
git log --oneline
gibt nur einen kurzen Kommentar an

Commit abändern

git commit --amend
übersc­hreibt letzten Commit
Vorsicht: Am besten nur bei lokalen Änderungen

Änderungen anzeigen

git diff
zeigt Änderungen zur staging area (z. working directory <-> staging area)
git diff --cached
zeigt gestagete Änderungen an (zw. staging area <-> Reposiory
git diff <ha­sh1> <ha­sh2>
zeigt Änderungen zw. zwei Commits
git diff <ha­sh1> <ha­sh2> --Date­i.txt

git log --date­i.css
fügt man " -- Datei.t­xt­" dann wird der "­dif­f" Befehl oder andere wie "­log­" Befehl nur aus dieser Datei gezeigt
mit -- datei.* werden alle Dateien genommen, die Datei. heißen (Beispiel datei.txt, datei.css etc.)
git diff <ha­sh1> <ha­sh2> Beispiel:
Mit "git log --onel­ine­" kann man die Historie sehen und nimmt sich dann zwei der linken ID's und fügt diese an die Stelle von hash1 und hash2 (Hash1 sollte am besten der Commit sein, der weiter in der Vergan­genheit liegt)

Änderungen durchf­ühren

git add <fi­le>
Datei in staging area übernehmen
git add <fo­lde­r>
ganzer Ordner in staging area übernehmen
git commit
**git commit -m "­<me­ssa­ge>­"
Commit aus allen getätigten Änderungen
Alternativ auch mit kurzer Commit­-Na­chricht
Mit "­Com­mit­" wird der Zustand des Projektes abgesp­eichert (quasi "­Ver­sio­n")
In Staging Are werden Commits vorber­eitet
Änderungen werden zunächst im working directors gelegt und müssen mit "git add" in die staging are gelegt werden
In der staging area sammeln wir alle Änderungen die wir vornehmen möchten
Mit "git commit­" speichern wir diese Änderungen auch in das Repository
(Best Practice: nur eine Änderung pro commit (ein Bug, ein neues Featur­e...)

Änderungen zurück­nehmen

Git Reset
git reset
nimmt alle Änderungen aus der stagin­g-area
**git reset <da­tei­nam­e>
nimmt diese Änderung aus stagin­g-area
Git Reset mit Commit
git reset <commit hash>
Löscht alle Commits nach <commit hash>. Alle Änderungen bleiben im working directory bestehen
git reset --hard <commit hash>
Löscht alle Commits nach <commit hash>. Änderungen werden verworfen

HEAD

HEAD
ist der gerade ausgec­heckte Commit
HEAD~1
ist der Parent vom gerade ausgec­heckten Commit (sprich eins vorher)
HEAD~2
Parent vom Parent vom gerade ausgec­heckten Commit
genutzt um z.B.
statt: git diff 239f87 98237dc
schreib man: git diff HEAD~2 HEAD

Änderungen zwisch­ens­pei­chern

Git Stash
aktuellen Zustand vom Working directory und der Staging Area zwisch­enz­usp­eichern
Beispi­el-­Wor­kflow: Du speicherst den Zustand im Stash, schaust dir einen alten Commit an, wechselst
wieder zum aktuellen Stand, und liest den alten Zustand aus dem Stash aus

Git Stash ist ein Last In First Out (Stack)
git stash (sichert den aktuellen Stand vom working directory)
git stash pop (stellt den letzten Stand vom working directory wieder her)
git stash list (zeigt alle Stashes an)
git diff stash (zeigt den diff des letzten Stashes an)

Änderungen rückgängig machen

git revert <commit hash>
Erstellt einen neuen Commit, der die Änderungen von <commit hash> rückgängig macht
Würde man eine Sache löschen, auf den die anderen Commits aufbauen, dann würde es zu einem Konflikt führen => werden gefragt, ob wir sie wirklich löschen wollen

(mit git reset --hard könnte man zu dem letzten commit springen und den aktuellen Löschv­organg beenden)

Datei ignorieren

.gitignore
Liste an Pfaden, die von git ignoriert werden
Änderungen an diesen Dateien haben dann keine Auswirkung auf git diff, git add, etc.
.gitignore sollte mit commitet werden

Bsp:
- Datei mit Passwörter oder Liste an Pfaden die ignoriert werden sollen.
- file/*.text würde bedeuten, dass alle .text Dateien in dem Ordner file ignoriert werden sollen

https:­//g­ith­ub.c­om­/gi­thu­b/g­iti­gnore ist eine Sammlung von möglichen .gitignore Dateien. (Aufpassen die Datei in.git­ignore umbene­nnen)

Datei löschen und umbenennen

git rm <da­tei>
löscht die Datei aus working directory und staging area
git mv <alter Datein­ame> <neuer Datein­ame>
bewegt die Datei
um Datei richtig zu löschen (working directory und staging area) -> git rm datei.txt

Datei umbene­nnen:
- mv index.html index2.html würde dazu führen, dass die Datei nur kopiert wird und damit die ganze Historie von index.html ebenfalls versch­windet
- richtig: *git mv index.html index2.html

Git blame

git blame <fi­len­ame>
zeigt Zeile für Zeile an, in welchem Commit diese zuletzt geändert wurde
git blame --colo­r-lines <fi­len­ame>
gleiche Commits farblich hervor­heben
git log -p -- <Da­tei­nam­e>
ist eine Altern­ative die alles im log Stil zeigt
git blame zeigt, wer welche Zeile geschr­ieben hat
--colo­r-lines führt dazu, dass gezeigt wird, welche Zeilen in einem commit hinzug­efü­gt/­geä­ndert wurden

Bran­ches

 

Git Branches

git branch
zeigt alle vorhan­denen Branches an
git branch <branch name>
legt einen neuen Branch an
git checkout <branch name>
wechselt zu einem Branch
Shortcut: git checkout -b <branch name>
legt einen neuen Branch an, und wechselt direkt dorthin
git log --online --graph --branches
gibt auch die Branches aus
"­Bra­nch­es" meint eine Verzwe­igung. Einer arbeitet an feature1 der andere an feature2, oder es wird in einer neuen branch ein Bug gefixt
Wenn dann ein feature fertig ist, wird es an der master­-branch gelegt

Der * bei git branch zeigt an, in welchem branch man sich gerade befindet
Genauso git log --online --graph --branches zeigt HEAD -> auf welchem Zweig man sich im Moment befindet

Branches mergen (Fast-­For­war­d-M­erge)

git merge <br­anc­h>
Versucht den Branch branch mit dem aktuellen Branch zusamm­enz­uführen
fast-f­orward Merge:
1) git checkout master, da wir von master aus das neue feature holen
2) git merge feature, damit holen wir uns das feature
3) git log --oneline --branches, müsste jetzt (HEAD -> master, feature) ausgeben
3) git branch -d feature, das feature am besten nach dem Merge löschen
4) git log --online --branches, müsste jetzt (HEAD -> master) ausgeben (feature wurde hinzug­efügt, jedoch sieht es aus, als hätte es ihn nie gegeben)

Branches mergen (Three­-Wa­y-M­erge)

Befehle sind die selben wie bei Fast-F­orw­ard­-Merge
Wenn kein Fast-F­orw­ard­-Merge möglich ist, da in Master ebenfalls Änderungen statt fanden

Three-­Way­-Merge
1) git log --oneline --branches --graph, Linien zeigen, was letzter gemeinsame Commit war & wie sich Pfad aufgeteilt hat
2) git checkout master, um in master zu wechseln
3) git merge <fe­atu­re>, git erkennt, dass Three-­Way­-Merge gemacht werden muss und merged automa­tisch (Best Practice: Die Zeile "­Merge branch 'feature' " so lassen, Zusatz­kom­mentar ist möglich

Merge-­Kon­flikte beheben

 
selben Befehle wie bei den Merge
1) Meldung, dass man den Konflikt manuell prüfen soll
2) wird gezeigt, welche Zeilen von welchem Commit kam
3) Code anpassen, Vorsicht!: Die Zeilen >>> HEAD, ... müssen gelöscht werden

Branch aktuell halten

git rebase <br­anc­h>
baut Commit­-Hi­storie basierend auf anderen Branch auf
git rebase -i <br­anc­h>
erlaubt es, dabei:
• Commits anzupassen (edit)
• Commit­-Me­ssages zu editieren (fixup)
• mehrere Commits zusamm­enz­ufassen (squash)
Die features werden nicht an dem älteren Branch, sondern an dem aktuel­lsten Branch gesetzt

Merge-­Str­ategien

git merge --no-ff
Verhin­dert, dass git einen fast-f­orw­ard­-Merge durchf­ührt. Es wird also immer ein Merge-­Commit erstellt.
git merge --ff-only
Erzwingt einen fast-f­orward Merge
NUR FAST-F­ORW­ARD­-MERGE
• Repository ist „in einem Strang“
• Dadurch einfach zu sehen, wie Änderungen aufein­ander aufbauen

NUR THREE-­WAY­-MERGE
• Jedes Feature in eigenen Branch entwickelt
• einfach zu sehen, wie welches Feature entwickelt wurde

Git tag

git tag -a v<x.y>
neuen Tag für Version x.y erstellen
git tag
alle besteh­enden Tags anzeigen
**git tag v<x.y> <co­mmi­t>
altem Commit eine Versio­nsn­ummer geben
Mit git tag kann man einen Release einer neuen Version markieren

bei git log sieht man dann den tag

GitHub

 

Remote­-Re­pos­itory clonen

git clone <ur­l>
erstel­ltl­okale Kopie des master­-Br­anches eines Reposi­tories
git remote -v
Ausfüh­rli­cher: git remote -vv
zeigt, welche remote Reposi­tories getrackt
clone:
1) git clone https:­//...
master ist dann unser lokales Repository
origin­/master ist unser remote Repository

Remote­-Wo­rkflow: fetch & pull

git fetch
lädt Commits und Branches von remote Repository herunter
git log origin­/<b­ran­ch>
git merge origin­/<b­ran­ch>
lädt Commits und Branches von remote Repository herunter
git pull
Shortcut beider Befehle (man muss in master sein)
zeigt, ob im Repository Änderungen vorgen­ommen wurden
- git fetch
oder:
- git log -- oneline --graph --branches zeigt den aktuellen Stand des lok Repository
git log -- oneline --graph --branches origin­/master zeigt den akt Stand des remote Reposi­tories an

um es zu mergen: git merge origin­/master, Shortcut: git pull

Einstieg in Github - Code auf GitHub laden

 
1) Repository erstellen
2) git remote add origin https:// link zum repository
3) *git push -u origin master

Änderungen zu GitHub übertragen

 
1) git status => Ausgabe sollte sein:
Auf Branch master
Ihr Branch ist auf demselben Stand wie 'origi­n/m­aster'
2) Bearbeite die Datei
3) git add datei.txt
4) git commit
5) git push (wenn jemand aber den origin­/master ändert, dann kommt es zu Konflikten -> Pull-R­equ­ests)

Änderungen übernehmen (Pull-­Req­uests)

 
1) git status wenn nicht auf akt Stand: git checkout master & git pull
2) git branch more-c­ontent & git checkout more-c­ontent (erstellt neue Branch und wechselt rein)
3) Datei bearbeiten & git add datei.txt & git commit
4) git checkout master & git pull
5) git checkout more-c­ontent

...

 
6) git rebase master
7) git push -> Fehler, wenn more-c­ontent keinen Upstre­am-­Branch => git push --set-­ups­tream origin more-c­ontent => Jetzt Änderungen in neuen Branch
8) oben rechts auf Compare & pull request -> Änderungen von more-c­ontent in master gemerged
9) git checkout master & git pull(Aktuelle auch Lokal)

GitHub Workflow: Readme & Markdo­wn-­Dat­eif­ormat

 
README.md
# Übersc­hrift 1.Ordnung
## Übersc­hrift 2.Ordnung (bis 6)

man kann die Wörter dick, kursiv, etc. format­ieren

Listen erstellen: mit Spiege­lst­richen, oder nummeriert

[link] (https:// wo führt der Link hin)

GitHub Workflow: Issues & Pull-R­equests

 
Genutzt, um zu schreiben, was geändert werden soll oder welcher Bug gefixt werden sollen

Assignes und Labels können angepasst werden

wie löse ich issues:
git branch bg-fix, git checkout bg-fix, Datei ändern, git add datei.txt, git commit (mit "­Fixes #Numme­r" angeben, welches Issues gefixt, git push / ... --set-­ups­tre­am..., Link kopieren um den Pull Befehl zu machen

Wörter wie Fixes, Resloves, etc können benutzt werden

GitHub Workflow: Collab­orator hinzufügen

 
Wie füge ich jemanden zum Repository hinzu:
Settings - Manage access - Invite a collab­orator

Um auf Master nicht mehr direkt commiten zu dürfen:
Settings - Branches - (Branch protection rules) Add rule - Branch name pattern: "­mas­ter­" - Require pull request reviews before merging ...

Fork & Pull-R­equ­ests; Fork Rebasen

 

Git Bisect

 
Verwen­dung:
git bisect start
git bisect bad [commi­t-id]
git bisect good [commi­t-id]
git bisect reset

Häufigsten Befehle

1) 
git clone https://

1) 
git pull
klont das git Repository in den lokalen Ordner
falls git clone schon ausgeführt
2) 
git status
zeigt ob geändert
3) 
git add Datein­ame­n.txt

3) 
git add .
geänderte Datei zur Staging Area
alle geänderten Datei zur Staging Area
4) 
git status
nochmal überprüfen
5 
git branch branchname
erstellt Branch mit dem Namen "­Bra­nch­nam­e"
6) 
git checkout branchname
Wechsel zur Branch
7) 
git commit -m "­Nac­hri­cht­"
commitet die geänderten Dateien
8) 
git push

eventuell: 
git push origin branchname
pusht ins Repository