Git ist ein Versionskontrollsystem
Das Erlernen von Git ist für jeden Programmierer unerlässlich. Es
hilft, die Arbeit im Team zu koordinieren und Ziele hinsichtlich der
Geschwindigkeit und Datenintegrität zu erreichen. Git ist ohne Zweifel
das beliebteste Open-Source-Versionskontrollsystem. Viele der
größten Unternehmen nutzen Git & GitHub für ihre Projekte.
"It makes working with other developers so much more exciting and
enjoyable, just by creating a new branch, adding all your brilliant
ideas to the code that can help the project, committing it, and then
pushing it to GitHub or GitLab." - Billy Iliev
Der Hauptvorteil der Versionskontrolle besteht darin, dass mehrere
Personen gleichzeitig am selben Projekt arbeiten können. Mit
Versionskontrolltools wie Git, können alle Änderungen am Code
nachverfolgt werden und im Falle von Problemen, kann man leicht zu
einem Stand zurückkehren, in dem der Code noch in einem
funktionierenden Zustand war.
Hinweis: Diese Seite fußt vor allem auf den Inhalten dieser Beiträge [1, 2 ] und dieses
Cheatsheets
, ergänzt es aber noch um einige Punkte.
Sehr zu empfehlen, um Git spielerisch zu lernen: Oh my git!
Die Essentials:
- git status - To remind you of where you left off. See a summary of local changes, remote commits, and untracked files.
- git diff - Um die spezifischen lokalen Änderungen an verfolgten Dateien anzuzeigen. Nutze --name-only , um geänderte Dateinamen anzugeben..
- git add - Um Änderungen an verfolgten und nicht verfolgten Dateien bereitzustellen. Nutze -u, -a, und .
- git commit - Um einen neuen Commit mit zuvor hinzugefügten Änderungen zu erstellen. Nutze -m und füge eine sinnvolle commit message hinzu.
- git push - Um Änderungen an unser konfiguriertes Remote-Repository zu senden.
Installieren & Setup von Git
Zunächst bei Google "GitHub" und dein Betriebssystem eingeben und dann Git
auf entsprechender Seite herunterladen. Das Video von Mosh (siehe unten)
hilft bei der Einrichtung von Git. Vorab sollte dein Lieblingsterminal (z.B. iTerm oder der integrierte Terminal in VSCode) und die Shell ausgewählt werden. Es gibt viele verschiedene Shells, wie bspw. Bash oder ZSH. Sie sind bereits integriert bzw. können auf unterschiedliche Weise eingerichtet werden (siehe Video unten zum Einrichten von Oh-my-zsh im
Terminal).
Git Version:
- git -- version (um zu sehen, welche Version wir haben)
Git Config:
-
git config -- global user.name "[Vorname Nachname]" (um den
Nutzernamen global festzusetzen)
-
git config -- global user.email "[valide Emailadresse]" (um die
Email global festzusetzen)
-
git config user.name || git config user.email (um zu sehen, was Git als Nutzername und Email gespeichert hat)
-
git config --global core.editor "code --wait" (damit sagen wir dem Terminal, dass er warten soll, bis wir das Editor-Fenster
geschlossen haben)
-
git config --global -e (gitconfig-file öffnet sich, dort können
Einstellungen angepasst werden)
-
git config --global core.autocrlf input (setzt automatische
Erstellung von Carriage Return auf LineFeed, da es sonst in der
Zusammenarbeit zwischen Windows und Mac Probleme geben
kann(windows:true, mac:input))
-
git config --global color.ui auto (setzt eine bunte
GitCommand-Zeile, für den besseren Durchblick)
-
git config --global alias.lg "log --oneline" (kreiiert einen Alias)
Getting Help:
- git <cmd> -h (schneller Überblick über die Befehle)
-
git <cmd> --help (ausführlicher Überblick über die Befehle)
Staging & Creating Snapshots
Initialization & Viewing the Status:
-
git init (erstellt ein Git-Repository im aktuellen Verzeichnis in Staging- Initialisierung)
- git status (um den vollständigen Status zu überprüfen, ob staged oder unstaged)
- git status -s(to check short status)
Adding Files to Staging Area:
- git add file1.js (um eine einzelne Datei zum Staging-Bereich hinzuzufügen)
-
git add file1.js file2.js (um mehrere Dateien zum Staging-Bereich hinzuzufügen)
- git add *.js (stagen nach Muster - hier .js)
-
git add . (um alle Dateien des aktuellen Verzeichnisses zum Staging-Bereich hinzuzufügen)
Removing Files:
-
git rm file1.js (um eine Datei zu entfernen und die Entfernung für den Commit bereitzustellen)
- git rm --cached file1.js (um eine Datei aus dem Staging-Bereich zu entfernen)
- git mv [existing-path] [new-path] (um einen vorhandenen Dateipfad zu ändern und diese Aktion zu stagen)
Commiting the staged files:
-
git commit -m "Specific Changes Made" (commits the staging area giving them a specific id)
- git commit -m (opens the default editor to type a long message)
- git commit -am "Message" (Skipping the staging area)
- --abbrev-commit (this can be used as an alias)
Viewing a commit:
- git show 921a2ff (Shows the given commit)
- git show HEAD (Shows the last commit)
- git show HEAD~2 (Two steps before the last commit)
-
git show HEAD:file.js (Shows the version of file.js stored in the last commit)
Unstaging files (undoing git add):
-
git restore --staged file.js (Copies the last version of file.js from
repo to index)
Discarding local changes:
-
git restore file.js (Copies file.js from index to working directory)
-
git restore file1.js file2.js (Restores multiple files in working
directory)
-
git restore . (Discards all local changes (except untracked files))
- git clean -fd (Removes all untracked files)
-
git restore --source=HEAD~2 file.js (Restoring an earlier version of a
file)
Viewing the staged/unstaged changes:
- git diff (Shows unstaged changes)
- git diff --staged (shows staged changes, which are not yet commited)
- git diff --cached(shows cached changes)
Viewing the history & Compare:
- git log (shows all the commits in the current branch history with details )
- git log --oneline (shows all the commits in one line each )
-
git log --reverse(List the commits from the oldest to the newest)
-
git log --follow [file] (show the commits that changed file, even across renames)
-
git log branchB...branchA(show the commits on branchA that are not on branchB)
-
git diff branchB...branchA(show the diff of what is in branchA that is not in branchB)
- git log --stat -M (show all commit logs with indication of any paths that moved)
-
git show [SHA] (show any object in Git in human-readable format)
-
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset
%s %Cgreen(%cr) %C(bold blue)<%an>%Creset' (this will log the info in
a nice format)
Branching wird verwendet, um eine neue Funktion oder einen neuen Code zu testen, indem eine Verzweigung erstellt wird.
Es ist besonders praktisch, wenn mehrere Entwickler an demselben Projekt arbeiten.
Für jedes Feature/ jeden Entwickler kann eine eigene Branch erstellt werden, die dann am Ende zusammengefügt(gemerged)
werden kann.
Managing branches:
- git branch (list your branches. a * will appear next to the currently active branch)
- git branch bugfix (Creates a new branch called "bugfix")
- git checkout (Switches to another branch amd check it out into your working directory)
z.B. git checkout bugfix (Switches to the bugfix branch)
- git switch bugfix (Same as the above)
- git branch -a (to list all the branches)
- git switch -C bugfix (Creates and switches)
- git branch -d bugfix (Deletes the bugfix branch, only when its been merged)
- git branch -D bugfix (Deletes the bugfix branch, even if not merged to master)
Comparing branches:
- git log master..bugfix (Lists the commits in the bugfix branch not in master)
- git diff master..bugfix (Shows the summary of changes)
Stashing:
- git stash (Save modified and staged changes)
- git stash push -m “New tax rules” (Creates a new stash)
- git stash list (Lists all the stashes)
- git stash pop (write working from the top of stash stack)
- git stash show stash@{1} (Shows the given stash)
- git stash show 1 (shortcut for stash@{1})
- git stash apply 1 (Applies the given stash to the working dir)
- git stash drop 1 (Deletes the given stash)
- git stash clear (Deletes all the stashes)
Merging:
- git merge [alias]/[branch] (Merge a remote branch into your current branch to bring it up to date)
- git merge bugfix (Merges the bugfix branch into the current branch)
- git merge --no-ff bugfix (Creates a merge commit even if FF is possible)
- git merge --squash bugfix (Performs a squash merge - only the commit after merge is shown in master
)
- git merge --abort (Aborts the mergeViewing the merged branches)
- git branch --merged (Shows the merged branches)
- git branch --no-merged (Shows the unmerged branches)
Rebasing:
- git rebase [branch] (Changes the base of the current branch. Only use it in private repos!! )
Cherry picking:
- git cherry-pick dad47ed (Applies the given commit on the current branch)
Viewing the history:
- git log --stat (Shows the list of modified files)
- git log --patch (Shows the actual changes (patches))
Filtering the history:
- git log -3 (Shows the last 3 entries)
- git log --author=“Mosh”
- git log --before=“2020-08-17”
- git log --after=“one week ago”
- git log --grep=“GUI” (Commits with “GUI” in their message)
- git log -S“GUI” (Commits with “GUI” in their patches)
- git log hash1..hash2 (Range of commits)
- git log file.txt (Commits that touched file.txt)
Formatting the log output:
- git log --pretty=format:”%an committed %H”
Viewing a commit:
- git show HEAD~2
-
git show HEAD~2:file1.txt (Shows the version of file stored in this
commit)
Comparing commits:
- git diff HEAD~2 HEAD (Shows the changes between two commits)
-
git diff HEAD~2 HEAD file.txt (Changes to file.txt onlyChecking out
a commit)
- git checkout dad47ed (Checks out the given commit)
- git checkout master (Checks out the master branch)
Finding a bad commit:
- git bisect start
- git bisect bad ( Marks the current commit as a bad commit)
-
git bisect good ca49180 (Marks the given commit as a good commit)
- git bisect reset (Terminates the bisect session)
Finding contributors:
- git shortlog
Viewing the history of a file:
- git log file.txt (Shows the commits that touched file.txt)
-
git log --stat file.txt (Shows statistics (the number of changes)
for file.txt)
-
git log --patch file.txt (Shows the patches (changes) applied to
file.txt)
Finding the author of lines:
-
git blame file.txt (Shows the author of each line in file.txt)
Tagging:
- git tag v1.0 (Tags the last commit as v1.0)
- git tag v1.0 5e7a828 (Tags an earlier commit)
- git tag (Lists all the tags)
- git tag -d v1.0 (Deletes the given tag)
Undoing Commits:
- git reset 72856ea (will remove all the commits after the provided id , but the files in local directory will not be touched)
-
git reset file1.js (unstage a file while retaining the changes in working directory)
-
git reset --soft HEAD&Hat (Removes the last commit, keeps changed
staged)
- git reset --mixed HEAD&Hat (Unstages the changes as well)
-
git reset --hard HEAD&Hat (Discards local changes Reverting commits)
Amending the last commit:
git commit --amend
Interactive rebasing:
git rebase -i HEAD~5
Reverting Commits:
- git revert 72856ea (Reverts the given commit)
-
git revert HEAD~3.. (Reverts the last three commits)
git revert --no-commit HEAD~3..
Recovering lost commits:
- git reflog (Shows the history of HEAD git)
- reflog show bugfix (Shows the history of bugfix pointer)
Am besten erstellt man direkt zu Beginn des Projekts eine spezielle Datei
namens .gitignore in der ignorierte Dateien geführt werden,
die im Root-Verzeichnis deines Repositorys eingecheckt werden.
Es gibt keinen expliziten "git ignore"-Befehl: Stattdessen
muss die .gitignore-Datei manuell bearbeitet und committet werden, wenn neue Dateien hinzukommen, die ignoriert werden sollen.
In dieser Datei kann spezifiziert werden, welche Ordner und Dateien, Muster
nicht gestaged oder commited werden sollen (z.B. build-Artefakte und maschinell generierte Dateien).
Weitere Beispiele:
- Abhängigkeits-Caches wie die Inhalte von /node_modules oder /packages
- Kompilierter Code wie .o-, .pyc- und .class-Dateien
- Build-Ausgabeverzeichnisse wie /bin, /out oder /target
- Während der Laufzeit generierte Dateien wie .log, .lock oder .tmp
- Versteckte Systemdateien wie .DS_Store oder Thumbs.db
- Persönliche IDE-Konfigurationsdateien wie .idea/workspace.xml
Quelle: Bitbucket
Befehl, dass das System das
Pattern in allen local Repositories ignoriert:
git config --global core.excludesfile[file]
GitIgnore-Generator
Creating a New Repository:
Create a new repo on Github and copy the URL & then push your code to
it
-
git push [alias]/[branch] (transmit local branch commits to the remote repository branch)
-
git push [git_url] master (pushing code of master branch Oder to push
all branches replace master with --all)
-
git remote add origin [git_url] (creating an alias to not always type
URL..origin can be name of anything else, but origin is the word
most commonly used)
- git push origin master (pushes master to origin)
-
git push -u origin master (pushes and starts tracking the branch -
you don't need to specify it again , ex. if pulling)
Cloning a Repository:
-
git clone [url] (will copy the repo to current directory and also
add the origin alias by default)
- git remote -vv (to check local& remote tracking branches)
-
git branch -r (helps us to see the remote branches & the
connections)
- git pull [git_url] (to pull changes from remote to local repo)
-
git push origin [branch_name] (to push the specific branch to remote)
Syncing with remotes:
- git fetch [alias](Fetches down all the branches from that Git remote)
- git fetch origin master (Fetches master from origin)
- git fetch origin (Fetches all objects from origin)
- git fetch (Shortcut for "git fetch origin")
- git pull (fetch + merge)
Sharing tags:
- git push origin v1.0 (Pushes tag v1.0 to origin)
- git push origin —delete v1.0
Sharing Branches:
- git push -u origin bugfix (Pushes bugfix to origin)
- git push -d origin bugfix (Removes bugfix from origin)
Managing Remotes:
- git remote (Shows remote repos)
-
git remote add upstream url (Adds a new remote called upstream)
- git remote rm upstream (Remotes upstream)