octocat-fanboy, Performance-Fetischist / verliebt in unmögliche Aufgaben und elegante Lösungen / Architekt und Entwickler bei spot-media AG (auch schon immer) @usefulthink | [email protected] | github.com/usefulthink
--decorate * d4ced12 (HEAD, arbeit) finished slides for js-days [5 minutes ago] |\ | * e455da1 (privat) founded decode-usergroup [5 months ago] * | d7055fd working with git, nodejs, Symfony2 [2 years ago] | * b1aa722 even more javascript, nodejs, nosql and git [3 years ago] | * d633722 javascript, extjs, yay! [4 years ago] | * ae31f22 graduated in computer engineering/computer vision [5 years ago] * | 24ed963 switch from cvs to svn [8 years ago] * | b86c85e programming in php, mysql [10 years ago] |/ * 3dfd4b3 start working at spot-media [10 years ago] * 263ed12 learned php/html/css/myqsl [10 years ago] :
can mean anything, depending on your mood. - random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant. - stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang. - "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room. - "goddamn idiotic truckload of sh*t": when it breaks Linus Torwalds, git README, initial commit (https://github.com/git/git/blob/master/README)
taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn‘t really expect anyone to use it because it‘s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black-t-shirt crowd. „
und Erreichbarkeit II. git-Objekte und Funktionsweise / Branches und Histories / Arbeit mit mehreren Repositories I. Repositories synchronisieren II. Workflows für verteiltes Arbeiten
~/src/git-test $ git config --global user.email “[email protected]“ ~/src/git-test $ git config --global color.ui auto git Konfigurieren (wird der Parameter --global weggelassen, wird die Konfiguration nur für das aktuelle Repository angepasst) Die globale Konfiguration von Git wird in der Datei ~/.gitconfig (ini- Format) im Home-Verzeichnis gespeichert, lokale Konfiguration findet sich im Projektverzeichnis unter .git/config
# Initial commit # nothing to commit (create/copy files and use "git add" to track) Änderungen und sonstige Status-Informationen des Repositories abfragen. ...oder sich sagen lassen was zu tun ist :)
git status # On branch master # # Initial commit # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # README.md nothing added to commit but untracked files present (use "git add" to track) Änderungen in den Index aufnehmen und für den nächsten Commit vorsehen.
# On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: README.md # machen wir das doch einfach mal...
dc69a36] first commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 README.md neuen Snapshot erzeugen DISCLAIMER: Um mich kurzzufassen werde ich keine besonders hilfreichen und/oder sinnvollen commit-messages schreiben. Normalerweise sterben Kätzchen durch solche commit-messages. (-m: commit-message direkt angeben; andernfalls öffnet sich euer $EDITOR)
# Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README.md # no changes added to commit (use "git add" and/or "git commit -a") ~/src/git-test $ git add README.md ; git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: README.md #
Martin Schuhfuss <m.schuhfuss@gmail> Date: Fri Jan 6 15:57:59 2012 +0100 first comit ~/src/git-test $ echo "Hello World" > README.md ~/src/git-test $ git diff diff --git a/README.md b/README.md index b7d6715..557db03 100644 --- a/README.md +++ b/README.md @@ -1 +1 @@ -Hallo Welt +Hello World Änderungen nachvollziehen Die Befehle git log und git diff sind extrem vielseitig einsetzbar, abhängig davon, mit welchen Parametern und Argumenten sie aufgerufen werden.
<datei>: Änderungen rückgängig machen und Datei im Arbeitsverzeichnis mit dem letzten Snapshot überschreiben*. git reset HEAD <datei>: Änderungen im Index / Staging- Bereich rückgängig machen*. git rm <datei>: Dateien löschen und aus dem Index entfernen * checkout und reset gehören mit zu den mächtigsten der git-Kommandos. Hier beschrieben ist nur einer der einfachsten der Anwendungsfälle.
Zyklus lässt sich die genaue zeitliche Abfolge der Ereignisse nicht mehr ablesen und es ergeben sich unendliche mögliche Abfolgen. Zeitliche Abfolgen können nur in zyklusfreien Graphen dargestellt werden.
gelauncht! d‘oh! neue Version Das. Killer. Feature. master nice_feature Revisions-Graph Erreichbarkeit awesomesauce 1 2 3 4 5 6 7 master 6 – 4 – 5 – 3 – 2 – 1 nice_feature 4 – 2 – 1 awesomesauce 7 – 5 – 3 – 2 – 1 alter kram Ist über keine der Referenzen zu erreichen! Die History sieht für jede Referenz anders aus
1 Version 2 Version 3 Version 4 Version 5 Δ2 Δ1 Δ2 Δ1 Δ2 Δ3 A B C Version 1 Version 2 Version 3 Version 4 Version 5 A1 B C1 A1 B C2 A2 B1 C2 A2 B2 C3 overall-state (exact copy) at a given time changes (Deltas) over time Git
Welt jemand eine leere Datei in einem git-repository speichert – mit welchem Betriebssystem und welcher git-Version auch immer – diese Datei wird immer denselben SHA1-Hash (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391) erhalten. Aufgrund der tatsächlichen Länge der SHA1-Hashes (160 bit / 2160 mögliche Kombinationen) ist es faktisch ausgeschlossen, dass zwei unterschiedliche Dateien mit denselben SHA1-Wert erhalten. Absolut und global Eindeutige Ids
Dies ist das eigentliche Projektverzeichnis und enthält die Dateien, mit denen ihr arbeitet. Staging-Bereich zur Vorbereitung von neuen Snapshots bzw. Commits Der HEAD-Commit zeigt auf den letzten erzeugten Snapshot im aktuellen Branch und ist immer der Snapshot, der zum Parent des nächsten Commits wird.
snapshot git add <file ...> git rm <file ...> git commit git reset <file ...> Die Dateien im Working Directory bleiben unverändert, die Änderungen werden aus dem Index entfernt HEAD repository
<file ...> unstage changes git reset <file ...> Die Dateien im Working Directory bleiben unverändert, die Änderungen werden aus dem Index entfernt Unter dem Titel „reset demystified“ gibt auf progit.org (http://progit.org/2011/07/11/reset.html) eine hervorragende Erklärung zu der genauen Funktionsweise von reset und checkout. Sowohl der Index als auch die Working-Copy werden zurückgesetzt
zum Parent-Commit HEAD …oder auch: der Commit, der zum Parent von neuen Commits wird eine Referenz für eine Commit-Id A, B, C usw. stehen als Platzhalter für die „echten“ Commit-Ids Mit jedem Commit wird die Referenz (master) des aktuellen Branches (vom HEAD angezeigt) automatisch mitbewegt.
fast-forward merge D HEAD master kein neuer commit Bei einem fast-forward merge wird kein separater merge-commit erzeugt, lediglich der Ziel-Branch (master) wird auf die neue Position „Vorgespult“. mit git merge --no-ff feature kann verhindert werden, dass fast- forward merges gemacht werden. Mit dem Parameter --ff-only werden sie erzwungen.
Merge! F G HEAD master H merge-commit ...hat im Gegensatz zu einem normalen Commit zwei Elternteile und wird aus den Änderungen der beiden Branches kombiniert. Commit-Message: merged branch ‘feature‘ Konflikte ...treten auf, wenn in beiden Branches in denselben Bereichen einer Datei Änderungen vorgenommen wurden
D‘ E‘ git checkout feature git rebase master HEAD feature git rebase nimmt alle Änderungen aus einem bestehenden Branch und verschiebt diese an eine andere Position. Die Basis (nearest common ancestor) des feature-Branches wird dabei von C zu G ACHTUNG nach dem rebase sind die Original-Commits nur noch über ihre Id erreichbar.
$ git rebase master First, rewinding head to replay your work on top of it... Applying: first feature commit Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging README.md CONFLICT (content): Merge conflict in README.md Failed to merge in the changes. Patch failed at 0001 first feature commit When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To check out the original branch and stop rebasing run "git rebase --abort". ~/src/git-test $ git rebase --abort
rebase master First, rewinding head to replay your work on top of it... Applying: first feature commit Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging README.md CONFLICT (content): Merge conflict in README.md Failed to merge in the changes. Patch failed at 0001 first feature commit When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To check out the original branch and stop rebasing run "git rebase --abort". Commit-Message des fehlgeschlagenen patches
# Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: web/style.css # # Unmerged paths: # (use "git reset HEAD <file>..." to unstage) # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: README.md # ~/src/git-test $ cat README.md <<<<<<< HEAD Hallo Welt! im branch master kommt was dazu... ======= Hello World >>>>>>> first feature commit Jeder Konflikt innerhalb der Datei wird mit Markierungen versehen. Die Datei wird bearbeitet, und der Konflikt aufgelöst, wobei die MArkierungen entfernt werden. rebase - Konflikte auflösen Der Vorwärtsgang
was dazu... ~/src/git-test $ git add README.md ~/src/git-test $ git stat # Not currently on any branch. # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: README.md # modified: web/style.css # ~/src/git-test $ git rebase --continue Applying: first feature commit Applying: second commit (add file) Applying: third commit (changed README.md) rebase - Konflikte auflösen Der Vorwärtsgang
you‘ll discover the easter-egg in git: all meaningful operations can be expressed in terms of the rebase-command. Once you figure that out it all makes sense. I thought the joke would be obvious […] „
rebase git rebase master feature-b --onto feature-a O‘ N‘ feature-b HEAD feature-b ~/src/git-test $ git rebase master feature-b --onto feature-a First, rewinding head to replay your work on top of it... Applying: first commit on branch feature-b (N $ N‘) Applying: second commit on branch feature-b (O $ O‘) from to new base
wenn in einer Datei Änderungen sind, die getrennt voneinander comitted werden sollen. git commit --amend: den letzen Commit nochmal bearbeiten. Üblicherweise zum Beheben von Tippfehlern in Commit-Messages aber auch git rebase --interactive: wie commit --amend auf Crack. Mit Kettensäge*. Erlaubt das beliebige Umstellen und nachträgliche Ändern von Commits. Unfassbar mächtig, aber mit Vorsicht zu genießen (vorher immer ein Tag setzen, dann kann man sich zumindest wieder retten, wenns was nicht klappt).
stash können alle gerade vorhandenen Änderungen „beiseite gelegt“ werden. Das Working-Directory und der Index werden auf den Stand des HEAD zurückgesetzt. stash pop stellt den beiseite gelegten Stand wieder her. git clean: Räumt unversionierte Dateien aus dem Weg, mit dem Parameter -f werden nur unversionierte Dateien entfernt, mit -d auch die Verzeichnisse. git mergetool: Die UNO oder sowas. Hilft bei der Konfliktlösung.
origin/feature A B C D origin/master master git clone erstellt ein neues Repository als exakte Kopie eines anderen Repositories. Dabei wird automatisch ein remote mit dem Namen origin angelegt. /home/robert/src/git-test
B C D origin/master /home/robert/src/git-test feature feature E X ...währenddessen ist Robert nicht untätig... Da keine automatische Synchronisierung stattfindet, ist das Abbild von origin/ feature jetzt veraltet.
Synchronisieren D C master origin/feature A B C D origin/master /home/robert/src/git-test E X feature X feature X feature F Kurzform: git pull origin feature
git pull martin feature ...und Rückwärts D C master A B C D /home/robert/src/git-test X X feature E F feature E F feature martin/master martin/feature F E master fast-forward merge
privates Repository Upstream Repository Der Maintainer hat die Aufgabe, aus den öffentlichen Repositories der anderen fertiggestellte Branches in das Upstream-Repository zu übernehmen und dort in den master-Branch bzw. in die release-Branches zu mergen. Dadurch werden sie allen Entwicklern zur Verfügung gestellt. Martins Öffentliches Repository Stefans Öffentliches Repository Roberts Öffentliches Repository Der Maintainer (Integrator) hat als einziger Schreibzugriff auf das Master-Repository und übernimmt Änderungen (Pull-Requests) von den anderen nur fetch/pull push „origin“ „upstream“
Änderungen oder zur eigenen Sicherheit. Private Branches sollten nie direkt veröffentlicht, sondern immer vorher bereinigt werden (merge --squash / rebase --interactive). upstream-branches: Branches für die Synchronisation mit einem upstream-repository. Diese dienen als Basis für Entwicklungsbranches, es sollten aber nie direkt commits in diesen gemacht werden. öffentliche Branches: Werden Beispielsweise für fertiggestellte Features oder Code-Reviews erstellt. Diese sollten zum besseren Verständnis eine bereinigte History (und brauchbare commit-messages!) haben. Änderungen im upstream-repository werden immer aus den öffentlichen Branches der Entwickler gemerged.
usefulthink
macloud
toru_kubota
koki_nishihara
oracle4engineer
.JPG){kind=avatar}
koh_naga
takakiyo
matsuihidetoshi
databricksjapan
shoota
emiki
doradora09
miyakemito
kneath
brianwarren
pedronauck
brad_frost
bkeepers
bluesmoon
nonsquared
akmur
chriscoyier
mraible
eileencodes
destraynor
![Martin Schuhfuß <[email protected]> – @usefulthink t$ git init started... @usefulthink](https://files.speakerdeck.com/presentations/506453fb888f95000200264f/slide_0.jpg){kind=link}
![Linus Torwalds in einem privaten Interview 2012 (http://typicalprogrammer.com?p=143) […] Eventually](https://files.speakerdeck.com/presentations/506453fb888f95000200264f/slide_70.jpg){kind=link}
![Fragen? @usefulthink | [email protected] | github.com/usefulthink](https://files.speakerdeck.com/presentations/506453fb888f95000200264f/slide_95.jpg){kind=link}