Javascript-Days 2012 – git started

Slide 1

Slide 1 text

Martin Schuhfuß – @usefulthink t$ git init started... @usefulthink | [email protected] | github.com/usefulthink Martin Schuhfuß

Slide 2

Slide 2 text

about me… Martin Schuhfuß / Hamburger (schon immer) / JS-Nerd, 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

Slide 3

Slide 3 text

me and git… ~/about/me $ git log --all --oneline --graph --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] :

Slide 4

Slide 4 text

git started...

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

http://geekandpoke.typepad.com/geekandpoke/2012/07/simply-explained-2.html

Slide 7

Slide 7 text

sorry, doesn‘t help.

Slide 8

Slide 8 text

sorry, doesn‘t help.

Slide 9

Slide 9 text

//////////////////////////////////////////////////////////////// ! GIT - the stupid content tracker //////////////////////////////////////////////////////////////// "git" 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)

Slide 10

Slide 10 text

New Oxford American Dictionary Urban Dictionary (http://www.urbandictionary.com/deﬁne.php?term=git)

Slide 11

Slide 11 text

Linus Torwalds in einem privaten Interview 2012 (http://typicalprogrammer.com?p=143) git has 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. „

Slide 12

Slide 12 text

Inhalt / Everyday git / Grundlagen und Hintergründe I. Graphen und Erreichbarkeit II. git-Objekte und Funktionsweise / Branches und Histories / Arbeit mit mehreren Repositories I. Repositories synchronisieren II. Workﬂows für verteiltes Arbeiten

Slide 13

Slide 13 text

! Inhalt / Warum Git? (siehe http://whygitisbetterthanx.com/) / Umgang mit graﬁschen Tools und IDE- Integration (ich bin bash-freund, seid es auch) / Viele, viele Varianten und mögliche Parameter der Git-Befehle

Slide 14

Slide 14 text

Everyday git Das wichtigste zum warmwerden…

Slide 15

Slide 15 text

init / clone ~/src $ mkdir git-test ; cd git-test ~/src/git-test $ git init Initialized empty Git repository in ../src/git-test/.git/ git-Repositories einrichten „GIT_DIR“ ~/src $ git clone http://github.com/geeksam/do-re-mi Cloning into 'do-re-mi'... remote: Counting objects: 31, done. remote: Compressing objects: 100% (23/23), done. remote: Total 31 (delta 6), reused 29 (delta 4) Unpacking objects: 100% (31/31), done. Remote-Repository

Slide 16

Slide 16 text

config ~/src/git-test $ git config --global user.name “Vor- und Nachname“ ~/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

Slide 17

Slide 17 text

config ~/src/git-test $ git config --global alias.hist \ ‘log --oneline --graph --decorate‘ ~/src/git-test $ git hist Aliase definieren… [alias] hist = log --oneline --graph --decorate sdiff = diff --staged st = status ci = commit --all ~/.gitconfig

Slide 18

Slide 18 text

status ~/local/src/git-test $ git status # On branch master # # 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 :)

Slide 19

Slide 19 text

add ~/src/git-test $ echo "Hallo Welt" > README.md ~/src/git-test $ git status # On branch master # # Initial commit # # Untracked files: # (use "git add ..." 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.

Slide 20

Slide 20 text

add ~/src/git-test $ git add README.md ~/src/git-test $ git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached ..." to unstage) # # new file: README.md # machen wir das doch einfach mal...

Slide 21

Slide 21 text

commit ~/src/git-test $ git commit -m 'first commit' [master (root-commit) 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)

Slide 22

Slide 22 text

weitere Änderungen ~/src/git-test $ git status # On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." 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 ..." to unstage) # # modified: README.md #

Slide 23

Slide 23 text

log und diff ~/src/git-test $ git log commit 2eee492f9f9941e18c0c1449dcfeb46c679ae080 Author: Martin Schuhfuss 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.

Slide 24

Slide 24 text

noch mehr... weitere Befehle für den alltäglichen Gebrauch git checkout : Änderungen rückgängig machen und Datei im Arbeitsverzeichnis mit dem letzten Snapshot überschreiben*. git reset HEAD : Änderungen im Index / Staging- Bereich rückgängig machen*. git rm : 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.

Slide 25

Slide 25 text

Ein bisschen Theorie Graphen und Erreichbarkeit.

Slide 26

Slide 26 text

places to be

Slide 27

Slide 27 text

places to be …ways to get there Nodes (Knoten) Edges (Kanten)

Slide 28

Slide 28 text

40seconds Javascript Days Hotel beer.js Gerichteter Graph Die Kanten haben eine Richtungsangabe und können nur in dieser Richtung verwendet werden Kanten haben eine einheitliche Bedeutung Zuhause Ich Zyklus Graphen

Slide 29

Slide 29 text

40seconds Javascript Days Hotel beer.js Zuhause Ich Graphen Durch den 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.

Slide 30

Slide 30 text

http://xkcd.com/657/

Slide 31

Slide 31 text

http://xkcd.com/657/

Slide 32

Slide 32 text

Krieg der Sterne Die Rache der Sith Das Imperium schlägt zurück Die Rückkehr der Jedi-Ritter Die dunkle Bedrohong Angriff der Klonkrieger 1 2 3 4 5 6 = Nachfolger (Produktionsreihenfolge) star-wars

Slide 33

Slide 33 text

Krieg der Sterne Die Rache der Sith Das Imperium schlägt zurück Die Rückkehr der Jedi-Ritter Die dunkle Bedrohong Angriff der Klonkrieger 1 2 3 4 5 6 = Nachfolger (Storyline) star-wars

Slide 34

Slide 34 text

Krieg der Sterne Die Rache der Sith Das Imperium schlägt zurück Die Rückkehr der Jedi-Ritter Die dunkle Bedrohong Angriff der Klonkrieger 1 2 3 4 5 6 = Geschichte baut darauf auf star-wars

Slide 35

Slide 35 text

erste halbwegs lauffähige Version Feature für neue Version beta endlich gelauncht! d‘oh! neue Version = wurde darauf aufgebaut Das. Killer. Feature. Revisions-Graph

Slide 36

Slide 36 text

erste halbwegs lauffähige Version Feature für neue Version beta endlich gelauncht! d‘oh! neue Version = wurde darauf aufgebaut Das. Killer. Feature. master nice_feature Revisions-Graph Referenzen awesomesauce

Slide 37

Slide 37 text

erste halbwegs lauffähige Version Feature für neue Version beta endlich 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

Slide 38

Slide 38 text

Wozu das alles? git wird niemals (wirklich nie) irgendetwas löschen, was über eine Referenz erreichbar ist. (Ihr dürft euch jetzt entspannen.)

Slide 39

Slide 39 text

Eintauchen git-Objekte und Funktionsweise

Slide 40

Slide 40 text

Snapshots CVS/SVN File A Δ1 File B File C Version 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

Slide 41

Slide 41 text

Git Objekte 5a9e02d9… loadClassCache(); $kernel->handle(Request::createFromGlobals())->send(); fe32a871… blob a501bc92… .htaccess blob 5a9e02d9… app.php blob 7e22a497… app_dev.php tree 2149b94c… css tree f02b2258… images ef129a71… ef129a71… Tree: Parent: Author: Comitter: fe32a871… a9d81ef3… Martin Martin Awesome commit-message is awesome. Awesome commit-message is awesome. Commit Tree Blob

Slide 42

Slide 42 text

Git Objekte ~/src/git-test $ tree . !"" README.md #"" web !"" index.html #"" style.css ~/src/git-test $ git add . ~/src/git-test $ git stat # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # new file: web/index.html # new file: web/style.css # ~/src/git-test $ git commit -m ‘index and styles‘ [master 6434aeb] index and styles 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 web/index.html create mode 100644 web/style.css

Slide 43

Slide 43 text

Git Objekte 636af660… Hallo Welt 97cd79d8… blob 636af660… README.md tree 6e6cee32… web 6434aeb7… 6434aeb7… Tree: Parent: 97cd79d8… 2eee492f… index and styles index and styles 2eee49… initial commit 6e6cee32… blob 94d985df… index.html blob e69de29b… style.css 94d985df… Hallo Welt!

Slide 44

Slide 44 text

SHA1 636af660… Hallo Welt e69de29b… Egal wo auf der 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

Slide 45

Slide 45 text

Three Trees working directory index HEAD repository Der aktuelle Checkout. 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.

Slide 46

Slide 46 text

unstage changes Three Trees working directory index stage changes create 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

Slide 47

Slide 47 text

Three Trees working directory index HEAD repository git reset --hard <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

Slide 48

Slide 48 text

working directory index HEAD repository repository master HEAD Beispiel

Slide 49

Slide 49 text

Hallo Welt working directory index HEAD repository repository master HEAD README.md echo “Hallo Welt“ > README.md

Slide 50

Slide 50 text

636af6... working directory index HEAD repository repository master HEAD README.md git add README.md README.md 636af6... Hallo Welt blob

Slide 51

Slide 51 text

working directory index HEAD repository repository master HEAD README.md git commit -m ‘initial commit‘ 636af6... README.md 636af6... README.md README.md: 636af6... 2eee49... master 2eee49... Tree: fd72bd... Author: Martin Comitter: Martin initial commit fd72bd... blob 636af6... README.md 636af6... Hallo Welt commit tree blob

Slide 52

Slide 52 text

Hallo Welt working directory index HEAD repository repository master HEAD README.md 636af6... README.md 636af6... README.md README.md: 636af6... 2eee49... master jetzt ändern wir die README.md… Hello World! README.md 636af6... Hallo Welt

Slide 53

Slide 53 text

Hello World! working directory index HEAD repository repository master HEAD README.md 636af6... README.md 636af6... README.md README.md: 636af6... 2eee49... master git add README.md 636af6... Hallo Welt 7e5411… README.md 7e5411… Hello World!

Slide 54

Slide 54 text

Hello World! working directory index HEAD repository repository README.md 636af6... README.md 7e5411... README.md README.md: 636af6... 2eee49... git commit -m ‘english‘ 636af6... Hallo Welt 7e5411… Hello World! README.md: 7e5411... f6ba12... 7e5411… README.md master HEAD master

Slide 55

Slide 55 text

Unterwegs Branches und Histories

Slide 56

Slide 56 text

A HEAD master master B C Szenario Commit Branch Verweis 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.

Slide 57

Slide 57 text

A B C git branch feature git checkout feature Branch erstellen master Kurzform: git checkout -b feature HEAD feature

Slide 58

Slide 58 text

A B C git commit … Branch erstellen D master HEAD feature

Slide 59

Slide 59 text

feature A B C git checkout master git merge feature 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.

Slide 60

Slide 60 text

A B C git checkout feature git commit … Ein weiterer Commit D E master HEAD feature

Slide 61

Slide 61 text

A B C D E HEAD master feature git checkout master git commit … Bugﬁxes… F G

Slide 62

Slide 62 text

C D E feature git checkout master git merge feature 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‘ Konﬂikte ...treten auf, wenn in beiden Branches in denselben Bereichen einer Datei Änderungen vorgenommen wurden

Slide 63

Slide 63 text

master D E C F G Konﬂikte vermeiden git rebase 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.

Slide 64

Slide 64 text

ups. irgendwas schief gelaufen? Komisches Zeug auf der Kommandozeile? Irgendwas falsch gemacht?

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

git wird niemals (wirklich nie) irgendetwas löschen, was über eine Referenz erreichbar ist. (Ihr dürft euch jetzt auch wieder entspannen.)

Slide 67

Slide 67 text

Der Rückwärtsgang --abort – Alles zurück auf Anfang ~/src/git-test $ $ 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

Slide 68

Slide 68 text

Der Vorwärtsgang rebase - Konﬂikte auﬂösen ~/src/git-test $ $ 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". Commit-Message des fehlgeschlagenen patches

Slide 69

Slide 69 text

~/src/git-test $ git stat # Not currently on any branch. # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: web/style.css # # Unmerged paths: # (use "git reset HEAD ..." to unstage) # (use "git add/rm ..." 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

Slide 70

Slide 70 text

~/src/git-test $ cat README.md Hello World im branch master kommt 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 ..." 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 - Konﬂikte auﬂösen Der Vorwärtsgang

Slide 71

Slide 71 text

Linus Torwalds in einem privaten Interview 2012 (http://typicalprogrammer.com?p=143) […] Eventually 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 […] „

Slide 72

Slide 72 text

N O master K L M feature-a moar fun with 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

Slide 73

Slide 73 text

Schweres Terrain Survival Tips und Werkzeug

Slide 74

Slide 74 text

hilfreiche Befehle git add --patch: interaktives Staging von Änderungen. Hilft, 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).

Slide 75

Slide 75 text

hilfreiche Befehle git stash und git stash pop: Mit git 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 Konﬂiktlösung.

Slide 76

Slide 76 text

mergetool http://www.perforce.com/downloads/complete_list (p4merge ist nur meine persönliche Empfehlung. Git kann mit so ziemlich jedem Tool umgehen, was 3-way-merges beherrscht.)

Slide 77

Slide 77 text

mergetool ~/src/git-test $ cd /opt/ && sudo tar -xvzf /path/to/downloaded/p4v.tgz ~/src/git-test $ cd /usr/local/bin && sudo ln -s /opt/p4v-/bin/p4merge ~/src/git-test $ git config --global merge.tool p4merge wenn ein Konﬂikt auftritt: ~/src/git-test $ git merge some-other-branch Auto-merging README CONFLICT (content): Merge conflict in README ~/src/git-test $ git mergetool Merging: README Normal merge conflict for 'README': {local}: modified file {remote}: modified file Hit return to start merge resolution tool (p4merge):

Slide 78

Slide 78 text

mergetool http://www.perforce.com/perforce/doc.current/manuals/p4v/merging_ﬁles.html

Slide 79

Slide 79 text

Der hilfreichste Befehl git help

Slide 80

Slide 80 text

http://ndpsoftware.com/git-cheatsheet.html Cheat! (mehr davon unter http://help.github.com/git-cheat-sheets)

Slide 81

Slide 81 text

Online-Hilfe / http://progit.org / http://marklodato.github.com/visual-git-guide / http://book.git-scm.com / http://think-like-a-git.net / http://gitimmersion.com

Slide 82

Slide 82 text

Allein sein ist blöd. Arbeit mit mehreren Repositories

Slide 83

Slide 83 text

feature A B git clone /home/robert/src/git-test clone D master C 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

Slide 84

Slide 84 text

clone git clone git://github.com/spot-media/git-demo git clone ../some/other/repository git clone erstellt ein exaktes Abbild eines anderen Repositories.

Slide 85

Slide 85 text

master A B git checkout -b feature origin/feature git commit … paralleles Arbeiten D C master origin/feature A B C D origin/master /home/robert/src/git-test feature feature E

Slide 86

Slide 86 text

master A B paralleles Arbeiten D C master origin/feature A 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 stattﬁndet, ist das Abbild von origin/ feature jetzt veraltet.

Slide 87

Slide 87 text

master A B git fetch origin feature git merge origin/feature 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

Slide 88

Slide 88 text

A B git remote add martin /home/martins/src/git-test git fetch martin 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

Slide 89

Slide 89 text

master A B git pull --rebase origin feature Das ganze ohne merges D C master origin/feature A B C D origin/master /home/robert/src/git-test E X feature feature X feature E‘ X

Slide 90

Slide 90 text

Und wie jetzt genau? Drei Workﬂows für das gemeinsame Arbeiten…

Slide 91

Slide 91 text

Distributed Workﬂow Martins Repository Stefans Repository Roberts Repository nur fetch/pull Anarchy

Slide 92

Slide 92 text

? Git Server (Blessed Repository) Martins Repository Stefans Repository Roberts Repository Shared Repository push/pull

Slide 93

Slide 93 text

git push origin feature Push? A B D C master X X master A B C D origin/master E X F feature origin/feature Shared-Repository Martins Repository F E feature

Slide 94

Slide 94 text

Integrator (z.B. github) Martins privates Repository Stefans privates Repository Roberts 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“

Slide 95

Slide 95 text

Branches in verteilten Repositories private Branches: temporäre Branches für experimentelle Ä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.

Slide 96

Slide 96 text

Fragen? @usefulthink | [email protected] | github.com/usefulthink