Kevin Read, profile picture
Hochgeladen vonKevin Read
108 aufrufe

Git class german / english

Das Dokument ist eine Einführung in die Verwendung von Git, GitHub und das Arbeiten mit Repositories, die Themen wie lokale Repositories, Versionskontrolle, das Forken von Projekten, und den Umgang mit Konflikten beim Zusammenführen von Änderungen behandelt. Es hebt die Wichtigkeit der Nutzung von Git für die Zusammenarbeit in Teams hervor und erklärt die verschiedenen Arbeitsabläufe mit Push- und Pull-Operationen. Zudem werden grundlegende Konzepte wie Commits, Branches und das Staging von Änderungen sowie die Probleme bei der Zusammenführung von Änderungen behandelt.

Präsentation einbetten

Downloaden Sie, um offline zu lesen
git isn’t sh*t It’s your friend An introduction in a lot of slides Kevin Read
Schedule • Why? ◀ • GitHub • Local git Repository • Collaborating • First aid
Why version stuff • In the “good” old days: • Pre-SVN: We send files via mail or sneakernet. If two people change the same file, we’re f***ed. • Post-SVN: “Please don’t update live, I committed unfinished changes” • We want versioning, but it is either complicated (SVN branches) or incomplete (CVS, SVN without branches)
git Workshop Where will it end us? • The goal is for you to understand the basic principles of git and to be fluent in its use. • This might be boring for you with git experience. But you guys might appreciate in-depth technical stuff that is marked with ☃ • Commands are shown for the command line and SourceTree (get it now) • So, git ready!
git Workshop Prerequisites • Get a git client: • Mac users: • Sourcetree (www.sourcetreeapp.com) • Xcode or git from Homebrew • Linux users: • sudo apt-get install git-cli • Windows: • Sourcetree (www.sourcetreeapp.com) For linux / CLI: # git config --global user.name ‘FIRST NAME’ # git config --global user.email ‘YOU@cliqz.com’
Schedule • Why? ✔ • GitHub ◀ • Local git Repository • Collaborating • First aid
About GitHub • GitHub is a company that offers commercial version control and associated services • Projects can be private (for internal code) or public (for open source) • We have an enterprise account and all code lives in private repositories • Eleni can create new projects for us • Typically only the owner has full access to a project
GitHub Issue tracker • GitHub also offers other services like an issue tracker or a Wiki • We use one central issue tracker for all of our projects. It can be found at https://github.com/cliqz/ bug-tracker/issues • When you find a bug, do a quick search to see if it’s already known • If not, create a report and include the following: • What were you trying to do when the issue appeared • What was the expected outcome • What happened instead • Is it reproducible?
GitHub Forking projects • The model we use is the pull & fork model • When Cliqzer “kevin-cliqz” wants to change a project called “cookies” owned by “luician-cliqz”, he forks it • The original project would be at http://github.com/cliqz/cookies, the fork at http://github.com/kevin-cliqz/cookies • kevin-cliqz can’t change the original project, but can do whatever he likes with his fork • Once he has made changes to his fork, he can tell lucian-cliqz to review and merge them in the original by issuing a pull request
Github Forking projects • So lets start by forking a small sample project • Go to github.com/kevin-cliqz/ playground and fork it. • You will now have a forked repository at github.com/ YOURNAMEHERE/playground • This is your own fork. You have full access to it, all other cliqzers can only read it.
Schedule • Why? ✔ • GitHub ✔ • Local git Repository ◀ • Collaborating • First aid
Local Repositories Cloning repositories • Now we need to clone this repository completely. • This makes an _exact_ copy of the repository • Later on we learn how to apply changes we make to one copy to its other clones • On the CLI do git clone URL, and in SourceTree • Important: It makes sense to have one folder called “git” where you create all clones
Local Repositories What is it? • A repository records all changes made to everything in one folder • So all files, folders, and files in folders :) • This folder is called working copy • ☃ Within the working copy you will find the repository itself within the hidden folder “.git” Working copy Repository
Local Repository Yeah, but what is it? • Internally, repositories are snapshots of past contents of the working copy ➡ We can reset the working copy into any of these snapshots of history - time machine style • Repositories never “forget”, they always grow • This also means they can use up quite a lot of space • (☃ Strictly speaking you can change history - but please don’t) ☃ Fun fact: Each snapshot is exactly that - it contains the complete state. Files that weren’t changed from the last commit are reduplicated by using hard links.
NB: In case you wondered that this sounds familiar… Yes, this is also how Apples Time Machine works and uses the same mechanics internally.
Local Repository Untracked files • Now lets create a file “cliqz.txt” and write something awesome there. • With git status we can see the state of both the repository and the working copy. • We can see the new file under “Untracked files” on the CLI and in SourceTree as marked with ➡ This means that the new file lies within the working copy but has not been added to the repository.
Local Repository Staging changes • Changes to the working copy can be added to the “Staging Area” with git add. • The staging area is the sum of all changes that will become the next snapshot in time after a “commit”. • git status will now show that the new files is in the staging area (“Changes to be committed”) ☃ The Staging Area (oder “Index”) is a Blob in .git/index
Local Repository Create commits • So add all changes that will create one coherent snapshot in time (called a “revision”) to the staging area. • You can add as many files at any time you want. • Using git commit the content of the staging area becomes a commit. • Each commit has a description that we can use later to remember what it was all about.
Local Repository Timeline • The time line (git log) now shows the first commit. • Now its time for a few further changes to the Repo: • Lets create a second file called “github.txt” and stage it. • Lets also add a few lines to “cliqz.txt” and also stage this. • Now commit both changes.
Local Repository So whats in a commit? • Each revision has these attributes on top of the description: • A unique identifier called SHA1 (its actually a checksum) • Author: Name and e-mail • Time and date of creation • List of files that were changed in this commit ☃ The SHA1 really is formed from the diff itself
Local Repository Working copy and time travel • Using the SHA1 of a revision you can turn your working copy into its state of the repository • This process is called a Checkout and can be achieved with git checkout. • In ST you double click on a revision • You can’t easily change this resurrected revision (its complicated)!
Local Repository Branches • We might all work on different tasks (“Hey can you fix this quickly?”) • So we need different lines of development (“heads” or “branches”) • Each repository initially has a branch called “master”. It’s the parent of all branches. • Every time you start working on a feature that won’t be finished in a day it’s a good idea to create a branch
Local Repository Branches, Tags • The working copy can be switched between branches at any time provided that you don’t have uncommitted files that would be changed by the branch switch • It’s always a good idea to check which branch is active before you start working! • It is also possible to bring changes you make to one branch onto another at a later time, but it’s a little bit of work. • Tags are labels you can attach to a certain commit (not to a branch)
Local Repository Zusammenfassung • Repositories save snapshots in time (“revisions”) of a folder (“working directory”) with all its contents. • Changes to these contents can be “staged” at any time. All staged changes are “committed” together with a comment and form a new revision. • You can have different “branches” of development and switch between them. • The working directory can be turned into any revision or branch.
Schedule • Why? ✔ • GitHub ✔ • Local git Repository ✔ • Collaborating ◀ • First aid
Collaborating Pushing and pulling • Up to now we only looked at working with a repository on your own computer (and yes, using git can make sense here too). • But the main reason to use a version control system is to easily work on the same set of files in a team without overwriting changes other people made. • We can “push” the changes we make to others • And we can “pull” the changes other team members have made to the files
Collaborating Workflow • Workflow: Pull from upstream, push to origin
Repositories teilen Eigenes Repository zu Server • Anwendungsfall: Eigenes Repo, mit dem bisher nur lokal gearbeitet wurde mit anderen teilen. • Wenn man dazu das eigene Notebook nicht immer angeschaltet lassen will braucht man einen Server :) • Dafür richtet ein Admin ein komplett leeres Repo ein. • Dort kann man dann das gesamte Repo rein schieben • Für den Workshop haben wir für jeden ein leeres Repo auf Martins Notebook angelegt. • Die URL dieses Repos ist ssh:// repo@IP/repo/USERNAME.git, also für Kevin ssh://repo@IP/repo/ kread.git • Schreibt euch diese URL erstmal auf :)
Repositories teilen Remotes • Wenn wir unser Repo jetzt in ein leeres Repo auf Martins Notebook pushen wollen müssen wir besagtes Notebook erstmal als “Remote” anlegen. • Ein Remote ist ein “befreundetes” Repository, mit dem wir Commits teilen. Remotes haben einen Namen und eine URL • Legen wir ein Remote namens “notebook” mit der URL von vorhin an
Repositories teilen Eigenes Repository zu Server Quellrepo Zielrepo Nach einem Push sieht das so aus:
Repositories teilen Push • Ein Push sorgt dafür, dass der Branch im Ziel-Repository (fremdes) auf den selben Commit zeigt wie der gleiche Branch im Quell-Repository (eures). • Dazu werden alle Commits kopiert, die nötig sind, damit die Timeline auf beiden Repos gleich ist. • Wenn das Ziel-Repo leer ist wird also einfach alles kopiert. • Wenn das Ziel-Repo schon Commits hat schaut git nach dem frühesten Commit, den beide gemeinsam haben und kopiert Commits ab da. • ☃ Fortgeschrittene User können mit einem Push alle möglichen abgefahrenen Sachen machen, etwa merges :D
Repositories teilen Push • Kopieren wir also unseren Branch “master” in das leere Repo des Remotes “notebook” • Das Häkchen bei “Track” (bzw. das “-u”) bedeutet, dass die Branches in beiden Repos sich merken, dass sie nach dem Push identisch sind. • Das spart etwas Handarbeit beim Pullen später, sonst müsste man beim pull immer angeben, aus welchem Remote und Branch gepulled wird.
Repositories teilen Push • Nach dem Push sehen wir, dass jetzt ein neuer Branch namens “notebook/ master” existiert. • Das ist die Kopie unseres Master- Branches auf diesem Remote. • Mit der Zeit werden beide Branches etwas auseinander laufen. Lets do this! • Dazu machen wir einen weiteren Commit in unseren Master. • ST bzw git status zeigt an, dass unser Branch vor dem Remote ist Pushed nun die neue Änderung zum Remote
Repositories teilen Klonen • In den meisten Fällen liegt ein Repository schon irgendwo auf einem Server • In diesem Fall wollen wir dieses Repo auf unseren Rechner klonen • Ein Klon kopiert alle Commits, Branches und Tags • Gleichzeitig legt er ein neues Remote namens “origin” an, das auf das ursprüngliche Repo auf dem Server zeigt. Damit kann man schnell Sachen dort hin pushen.
Repositories teilen Unser erster Klon • Holt euch von eurem linken Nachbarn die URL seines Repos und klont dieses in einen Ordner auf eurer Platte. • Mit ST auf File/New • Nun legt hier eine Datei namens “hallo.txt” mit einem freundlichen Gruß an und committet diese. • Und dann an das Remote pushen :)
Repositories teilen Zusammenfassung • Repositories können ganze Branches in andere Repositories schieben. • Ein bestehendes Repository kann über das Netzwerk / Internet komplett geklont werden. • Jedes Repo ist dabei ein vollständiges Repo mit Branches und Arbeitskopie. • Mit jedem Repo kann komplett unabhängig gearbeitet werden!
Fahrplan • Warum? ✔ • Lokales Repository ✔ • Repositories teilen ✔ • Fremde Änderungen einpflegen ◀ • Erste Hilfe
Fremde Änderungen einpflegen Konfliktpotential • Ihr habt das Repo vom linken Nachbarn auf Martins Notebook verändert und eure Änderungen gepushed. • Wenn euer linker Nachbar zwischenzeitlich keine Commits gemacht hat kann er euren Commit sehr einfach bei sich einspielen. • Hat er jedoch zwischenzeitlich auch Änderungen gemacht kann es zu Konflikten kommen. • Selbst ohne Konflikte gibt es zwei unterschiedliche Timelines. Es gibt verschiedene Strategien, wie diese wieder zusammen geführt werden können.
Fremde Änderungen einpflegen Konfliktpotential • Nehmen wir den einfachen Fall. • Auf eurem eigenen Repo aktualisieren wir jetzt nun unsere Information über alle Branches auf unserem Remote. • Zur Erinnerung: Euer Remote ist auf Martins Notebook, das euer rechter Nachbar gerade geändert hat. • ST macht das von selbst, auf der Konsole genügt git fetch und dann git status
Fremde Änderungen einpflegen Commits holen • git weiss jetzt, dass der master- Branch auf remote aktueller ist als der eigene “master”. • Wenn wir diese Commits auch bei uns haben möchten, brauchen wir git pull • ☃ Ein git merge genügt nicht, da ein git pull mehr ist als ein git fetch; git merge (zB wenn in einem Commit nur ein Branch auf einen andere SHA1 zeigt)
Fremde Änderungen einpflegen Fast-Forward! • Das Ergebnis ist, dass “master” und “notebook/master” wieder auf den gleichen Commit zeigen - wir sind up-to-date. • Dies ging jetzt nur so einfach, weil zwischenzeitlich nichts am eigenen Repo geändert wurde. “master” hier ist also ein Vorfahre von “master” auf notebook. • git kann daher einen “Fast Forward”- Merge machen, also einfach die neueren Commits vor den eigenen rein kopieren. • Schauen wir uns einen komplexeren Fall an.
Fremde Änderungen einpflegen Echtes Szenario #1 • Bittet euren rechten Nachbarn (der also euer Repo geklont hat) eine Änderung an der hallo.txt zu machen. • Ihr macht gleichzeitig eine Änderung an der wiegsagt.txt. • Ihr committed beide eure Änderung. • Nachbar pusht, ihr macht einen Fetch. • Ihr seht in ST, dass jetzt zwei Heads existieren. • Wenn ihr jetzt pulled, müssen beide Linien zusammen geführt werden.
Fremde Änderungen einpflegen Echtes Szenario #1 • Mit einem git pull oder dem Pull-Befehl in ST werden die Linien zusammen geführt. • Dazu wird ein so genannter “Merge Commit” angelegt. Dieser hat nicht einen Vorgänger in der Timeline, sondern gleich zwei. • Auf der Kommandozeile wird man auch nach der Commit-Message gefragt. • Pushed diesen Merge Commit und euren eigenen zurück auf notebook
Fremde Änderungen einpflegen Merge Commits • Merge Commits haben ihre Daseinsberechtigung. • Wenn man zwei echte Branches zusammen führt ist es vorteilhaft wenn man sieht was hier passiert ist. • Aber bei der gemeinsamen Arbeit an einem Branch machen sie nur das Lesen der Historie schwerer. • Stattdessen haben wir uns alle auf rebase geeinigt. Das Beispiel oben ist krass, aber sowas kann passieren!
Fremde Änderungen einpflegen Echtes Szenario #1 mit Rebase • Also nochmal ran. Euer Nachbar soll noch einmal die Datei hallo.txt verändern, committen und pushen. • Ihr verändert die wiegsagt.txt und committed, dann ein Pull, aber diesmal mit Rebase. • In ST gibt es dafür eine Checkbox, auf der Kommandozeile mit git pull -r • What just happened?
Fremde Änderungen einpflegen Echtes Szenario #1 mit Rebase • Rebase sucht genauso wie pull bzw. merge den neuesten Commit, den beide branches gemein haben. • Von diesem ausgehend werden die Commits, die auf das eigene Repo gemacht wurden entfernt und in eine Zwischenablage gelegt. • Nun werden die Commits vom Quell-Repo eingespielt. • Danach alle Commits aus der Zwischenablage. • Nachteil: Die Historie wurde geändert. Merke: Kein rebase nach push! • ☃ Frage: Warum?
Fremde Änderungen einpflegen Probleme beim Zusammenführen • Unabhängig davon, ob merge oder rebase verwendet wird, kann es beim Zusammenführen Probleme geben. • Wenn in beiden Repos dieselben Stellen in den gleichen Dateien verändert wurden, weiß git nicht, welche Änderung jetzt die richtige ist. • Dann kommt der schöne, heißgeliebte Konflikt-Dialog.
Fremde Änderungen einpflegen Echtes Szenario #2 • Verursachen wir also einen Konflikt. • Dein Nachbar soll die Datei “wiegsagt.txt” öffnen und ganz unten eine Zeile hinzufügen, committen und pushen. • Du fügst auch eine Zeile hinzu und committest. • Wenn du jetzt pullst, wird es einen Konflikt geben, da git nicht weiß welche hinzugefügte Zeile korrekt ist.
Fremde Änderungen einpflegen Soft Skill : Konflikte • Dateien mit Konflikten werden in ST mit Ausrufezeichen versehen und in git status extra hervorgehoben. • Der Konflikt muss jetzt von einem Menschen von Hand behoben werden. Dazu gleich mehr. • So lange der Konflikt nicht behoben ist kann nicht wirklich committed, gepulled oder sonstwas werden. • Konflikte beim rebasen verhalten sich etwas anders, aber nicht grundlegend.
Fremde Änderungen einpflegen Einfache Konfliktlösung • ST bietet euch einfach die Möglichkeit, den Konflikt in einer Datei zu beheben: • Ihr könnt eure Änderungen oder die Änderungen vom Quell-Repo komplett zu verwerfen. • Dies betrifft nur die Änderungen, die im Konflikt sind, alle anderen veränderten Zeilen der Commits sind ok. • Wird eher selten benötigt.
Fremde Änderungen einpflegen Händische Konfliktlösung • Die meisten Konflikte sind komplexer und müssen in der Datei selbst bearbeitet werden. • Öffnet die Datei wiegsagt.txt in eurem Editor. • Der Teil zwischen “===“ und “<<<“ ist üblicher weise die Textstelle, so wie so vom Fremd-Repo kommt. • Von “===“ bis “>>>” die Textstelle, die von euren Commits stammt. • An den Klammern stehen jeweils die Commits, die den Konflikt verursacht haben • Bei rebase steht statt Fremd-Commit “HEAD” (☃ weiß wer warum?) <<<<<<< HEAD Zum Konflikt von Martin ======= Zum Konflikt von Kevin >>>>>>> Von Kevin Fremd-Textstelle Eigene Textstelle
Fremde Änderungen einpflegen Händische Konfliktlösung • Entscheidet euch für eine der beiden Textstellen und entfernt die andere. • Oder: Kombiniert beide! • Wenn ihr euch nicht sicher seid was los ist, sprecht mit dem Autor der konfliktverursachenden Änderungen!!!! • Wichtig: Die Zeilen mit <<<, >>> und === müssen mit entfernt werden. • Das Ergebnis kann als konfliktfrei markiert werden. <<<<<<< HEAD Zum Konflikt von Kevin und Martin ======= Zum Konflikt von Kevin >>>>>>> Von Kevin
Fremde Änderungen einpflegen Nach dem Konflikt • Fügt nun die von euch bereinigte Datei ganz normal zur Staging Area und drückt in ST auf Commit • Auf der Kommandozeile git add gefolgt von git rebase —continue (falls ihr gerade rebased) oder git commit • Ihr könnt in ST auch per Rechtsklick als resolved markieren, das entfernt schon mal die Markierung • Danach natürlich brav pushen.
Fremde Änderungen einpflegen Zusammenfassung • Es gibt verschiedene Möglichkeiten um Commits in anderen Repos in euer Repo zu bringen. • Rebase ist im Allgemeinen euer Freund, solange ihr nicht einen großen Feature- Branch mergen wollt. • Konflikte von Hand beheben ist schnell gelernt. Ruhig bleiben und tief durchatmen. Im Ernstfall Fat Boy treten. • Bei seltsamen Konflikten im Log herausfinden wer Schuld ist und lieber nachfragen.
Fahrplan • Warum? ✔ • Lokales Repository ✔ • Repositories teilen ✔ • Fremde Änderungen einpflegen ✔ • Erste Hilfe ◀
Erste Hilfe Was tun wenns brennt? • Manchmal geht auf einmal nichts mehr (“es geht einfach nicht”), und git verweigert commit, pull, oder push. • Oft gibt es dazu auch eine hilfreiche Fehlermeldung (“Du musst erst pullen bevor du pushen kannst”, “du kannst nicht rebasen wenn du uncommittete Änderungen hast”, …) • Manchmal scheint aber auch einfach alles im Arsch zu sein. • Erste Regel des git-Clubs: Nicht pushen wenn kaputt!!! • Zweite Regel: Keine Panik. Vielleicht helfen euch diese Faustregeln.
Erste Hilfe Warum git manchmal nicht pullen mag • Git hat als oberste Faustregel, dass keine Änderungen verloren gehen dürfen. • Daher mag git auch keine uncommitteten Änderungen überschreiben oder Commits pullen, die eure lokale Historie zerballern würden. • Daher Faustregel: Wenn nicht alles sauber committed ist, könnt ihr nicht pullen und erst recht nicht rebasen. • Committed, nicht gepushed! • Am einfachsten und saubersten ist es, wenn ihr nur Dateien verändert, die zum aktuellen Task gehören und danach alle diese Dateien am Stück committed. • Wenn ihr Dateien geändert habt die nicht zum aktuellen Task gehören, aber die Änderungen sind wichtig, dann einfach zwei Commits machen :) • Wenn auch das nicht geht -> Stash.
Erste Hilfe Stash it! • Der Stash (englisch für Beutelager) ist ein geheimes Versteck für Änderungen, die ihr zur Zeit nicht committen könnt. • Ihr legt immer alle uncommitteten Änderungen in den Stash und gebt der Sache einen Namen. • Danach ist die Arbeitskopie sauber und ihr könnt pullen etc. • Probiert es aus: wiegsagt.txt ändern, dann git stash save oder in ST
Erste Hilfe Stash it! • Mit git stash list seht ihr, was sich alles in eurem geheimen Hort befindet, bzw bei ST in der linken Leiste. • Ihr könnt ein Paket an Änderungen zu einem späteren Zeitpunkt aus dem Stash holen und auf den aktuellen Branch anwenden. Der Stash-Eintrag wird dabei auf Wunsche gelöscht (git stash pop) • Danach normal weiter arbeiten und committen. ☃ git stash pop vs apply
Erste Hilfe Fiese Fremdeinflüsse • Bei Problemen beim Pullen hilft es oft zu schauen, wie die Remotes aussehen, also die Repos, die “befreundet” sind. • Wo ist euer Branch aktuell in der Timeline? Wo derselbe Branch im Remote? Ist HEAD irgendwo seltsam unterwegs? • Wenn das alles nichts hilft und ihr euch sicher seid, dass ihr keine nicht gepushten Commits habt, dann hilft die Radikalkur.
Erste Hilfe Radikalkur • Die Radikalkur sorgt dafür, dass ein Branch im Repo gestutzt wird. • Die Spitze des Branch wird auf einen bestimmten Commit oder Branch gesetzt, und alles dahinter wird verworfen. • Am häufigsten wird damit das eigene Repo auf den gleichen Stand wie ein Remote gebracht: • git reset —hard REMOTE/ BRANCH
Erste Hilfe Zusammenfassung • git verhindert fast immer, dass Änderungen verloren gehen. • Das sieht dann manchmal so aus, als ob es euch hasst und ärgern will. • Wenn nix mehr geht: stachen • Wenn gar nix mehr geht: git reset • Im Zweifelsfall lieber fragen bei Problemen. Nie pushen!
git is shit? No, git is it! • Wenn man einige Zeit mit git gespielt hat ist alles nicht mehr so seltsam. • Ein gute grafische App hilft enorm. • Wenn ein Problem dort seltsam aussieht hilft manchmal auch ein git status auf der Kommandozeile. • Ich hoffe, ihr habt was gelernt. • Viel Spaß, wie gsagt!

Weitere ähnliche Inhalte

PDF
git - eine praktische Einführung
vonMarcel Eichner
 
PDF
GIT / SVN
vonTorben Brodt
 
PDF
Deployment von Entwicklungsumgebungen eines TYPO3-Intranets mit Vagrant
vonChristoph Möller
 
PDF
Versionskontrolle mit Subversion und Git
vonpaultcochrane
 
PPTX
Continuous Delivery
vonSteffen Gebert
 
PDF
Sei (k)ein Blödmann und nimm Git!
vonStefan Imhoff
 
PDF
Git Grundlagen
vonBenjamin Schürmann
 
PDF
Einsatz von Git im Unternehmen
vonoose
 
git - eine praktische Einführung
vonMarcel Eichner
 
GIT / SVN
vonTorben Brodt
 
Deployment von Entwicklungsumgebungen eines TYPO3-Intranets mit Vagrant
vonChristoph Möller
 
Versionskontrolle mit Subversion und Git
vonpaultcochrane
 
Continuous Delivery
vonSteffen Gebert
 
Sei (k)ein Blödmann und nimm Git!
vonStefan Imhoff
 
Git Grundlagen
vonBenjamin Schürmann
 
Einsatz von Git im Unternehmen
vonoose
 

Was ist angesagt?

PDF
Git vs SVN - Eine vergleichende Einführung
vonMario Müller
 
PDF
Perl Renaissance Reloaded
vonGregor Goldbach
 
PDF
PHP Deployment mit Ansible
vonMichael Döhler
 
PPT
Entwicklungsprozess und Arbeit mit Symfony2 in der fotocommunity GmbH
vonstijink
 
PDF
Welches Versionskontrollsystem sollte ich nutzen? (SVN, Git, Hg)
vonMichael Whittaker
 
PDF
TechTalkThursday 26.11.2015: Manage the minions - Docker Container mit Kubern...
vonnine
 
PDF
Deployment
vonChristian Händel
 
PDF
Gitlab
vonheiglandreas
 
KEY
Git vs SVN DevCon 2011
vonMario Müller
 
PDF
Technische Gründe für schlechte Entwicklungsperformance
vonOPEN KNOWLEDGE GmbH
 
PDF
TechTalkThursday: Zentrales Metriken-System - ist der Flügelschlag des Schmet...
vonBenjamin Kuster
 
PDF
Entwicklung mit Chef und Vagrant - PHPUG HH
vonFlorian Holzhauer
 
PDF
Jenkins Acceleration
vonPatrick Paechnatz
 
PDF
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
vonQAware GmbH
 
PDF
Docker Einführung @GPN15
vonm1no
 
ODP
Von Test nach Live mit Rex
vonJan Gehring
 
Git vs SVN - Eine vergleichende Einführung
vonMario Müller
 
Perl Renaissance Reloaded
vonGregor Goldbach
 
PHP Deployment mit Ansible
vonMichael Döhler
 
Entwicklungsprozess und Arbeit mit Symfony2 in der fotocommunity GmbH
vonstijink
 
Welches Versionskontrollsystem sollte ich nutzen? (SVN, Git, Hg)
vonMichael Whittaker
 
TechTalkThursday 26.11.2015: Manage the minions - Docker Container mit Kubern...
vonnine
 
Deployment
vonChristian Händel
 
Gitlab
vonheiglandreas
 
Git vs SVN DevCon 2011
vonMario Müller
 
Technische Gründe für schlechte Entwicklungsperformance
vonOPEN KNOWLEDGE GmbH
 
TechTalkThursday: Zentrales Metriken-System - ist der Flügelschlag des Schmet...
vonBenjamin Kuster
 
Entwicklung mit Chef und Vagrant - PHPUG HH
vonFlorian Holzhauer
 
Jenkins Acceleration
vonPatrick Paechnatz
 
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
vonQAware GmbH
 
Docker Einführung @GPN15
vonm1no
 
Von Test nach Live mit Rex
vonJan Gehring
 

Ähnlich wie Git class german / english

PDF
Version management mit Git und Github
vonfg.informatik Universität Basel
 
PDF
Einführung in Git
vonandreaswo
 
PDF
"git.net" gibt's nicht?
voninovex GmbH
 
PDF
Gitことはじめ
vonbleis tift
 
PDF
Git Power-Workshop
vonSteffen Gebert
 
PDF
Versionskontrolle mit Git
vonNETUserGroupBern
 
PDF
Minimum introduction to Git
vonRonny
 
PDF
Git barcamp stuttgart_2010
vonwebholics
 
PPT
Do it the_git_way
vonPeter Ukena
 
PDF
git Vorstellung
vonSven-S. Porst
 
PPTX
Versionierung mit GIT
vongedoplan
 
PDF
Git
vonGordon Franke
 
PDF
Verteilte Versionskontrolle mit Git
vonDevDay Dresden
 
PDF
Verteilte Versionskontrolle mit Git
vonJan Dittberner
 
Version management mit Git und Github
vonfg.informatik Universität Basel
 
Einführung in Git
vonandreaswo
 
"git.net" gibt's nicht?
voninovex GmbH
 
Gitことはじめ
vonbleis tift
 
Git Power-Workshop
vonSteffen Gebert
 
Versionskontrolle mit Git
vonNETUserGroupBern
 
Minimum introduction to Git
vonRonny
 
Git barcamp stuttgart_2010
vonwebholics
 
Do it the_git_way
vonPeter Ukena
 
git Vorstellung
vonSven-S. Porst
 
Versionierung mit GIT
vongedoplan
 
Git
vonGordon Franke
 
Verteilte Versionskontrolle mit Git
vonDevDay Dresden
 
Verteilte Versionskontrolle mit Git
vonJan Dittberner
 

Git class german / english

  • 1.
    git isn’t sh*t It’syour friend An introduction in a lot of slides Kevin Read
  • 2.
    Schedule • Why? ◀ •GitHub • Local git Repository • Collaborating • First aid
  • 3.
    Why version stuff •In the “good” old days: • Pre-SVN: We send files via mail or sneakernet. If two people change the same file, we’re f***ed. • Post-SVN: “Please don’t update live, I committed unfinished changes” • We want versioning, but it is either complicated (SVN branches) or incomplete (CVS, SVN without branches)
  • 4.
    git Workshop Where willit end us? • The goal is for you to understand the basic principles of git and to be fluent in its use. • This might be boring for you with git experience. But you guys might appreciate in-depth technical stuff that is marked with ☃ • Commands are shown for the command line and SourceTree (get it now) • So, git ready!
  • 5.
    git Workshop Prerequisites • Geta git client: • Mac users: • Sourcetree (www.sourcetreeapp.com) • Xcode or git from Homebrew • Linux users: • sudo apt-get install git-cli • Windows: • Sourcetree (www.sourcetreeapp.com) For linux / CLI: # git config --global user.name ‘FIRST NAME’ # git config --global user.email ‘YOU@cliqz.com’
  • 6.
    Schedule • Why? ✔ •GitHub ◀ • Local git Repository • Collaborating • First aid
  • 7.
    About GitHub • GitHubis a company that offers commercial version control and associated services • Projects can be private (for internal code) or public (for open source) • We have an enterprise account and all code lives in private repositories • Eleni can create new projects for us • Typically only the owner has full access to a project
  • 8.
    GitHub Issue tracker • GitHubalso offers other services like an issue tracker or a Wiki • We use one central issue tracker for all of our projects. It can be found at https://github.com/cliqz/ bug-tracker/issues • When you find a bug, do a quick search to see if it’s already known • If not, create a report and include the following: • What were you trying to do when the issue appeared • What was the expected outcome • What happened instead • Is it reproducible?
  • 9.
    GitHub Forking projects • Themodel we use is the pull & fork model • When Cliqzer “kevin-cliqz” wants to change a project called “cookies” owned by “luician-cliqz”, he forks it • The original project would be at http://github.com/cliqz/cookies, the fork at http://github.com/kevin-cliqz/cookies • kevin-cliqz can’t change the original project, but can do whatever he likes with his fork • Once he has made changes to his fork, he can tell lucian-cliqz to review and merge them in the original by issuing a pull request
  • 10.
    Github Forking projects • Solets start by forking a small sample project • Go to github.com/kevin-cliqz/ playground and fork it. • You will now have a forked repository at github.com/ YOURNAMEHERE/playground • This is your own fork. You have full access to it, all other cliqzers can only read it.
  • 11.
    Schedule • Why? ✔ •GitHub ✔ • Local git Repository ◀ • Collaborating • First aid
  • 12.
    Local Repositories Cloning repositories •Now we need to clone this repository completely. • This makes an _exact_ copy of the repository • Later on we learn how to apply changes we make to one copy to its other clones • On the CLI do git clone URL, and in SourceTree • Important: It makes sense to have one folder called “git” where you create all clones
  • 13.
    Local Repositories What isit? • A repository records all changes made to everything in one folder • So all files, folders, and files in folders :) • This folder is called working copy • ☃ Within the working copy you will find the repository itself within the hidden folder “.git” Working copy Repository
  • 14.
    Local Repository Yeah, butwhat is it? • Internally, repositories are snapshots of past contents of the working copy ➡ We can reset the working copy into any of these snapshots of history - time machine style • Repositories never “forget”, they always grow • This also means they can use up quite a lot of space • (☃ Strictly speaking you can change history - but please don’t) ☃ Fun fact: Each snapshot is exactly that - it contains the complete state. Files that weren’t changed from the last commit are reduplicated by using hard links.
  • 15.
    NB: In caseyou wondered that this sounds familiar… Yes, this is also how Apples Time Machine works and uses the same mechanics internally.
  • 16.
    Local Repository Untracked files •Now lets create a file “cliqz.txt” and write something awesome there. • With git status we can see the state of both the repository and the working copy. • We can see the new file under “Untracked files” on the CLI and in SourceTree as marked with ➡ This means that the new file lies within the working copy but has not been added to the repository.
  • 17.
    Local Repository Staging changes •Changes to the working copy can be added to the “Staging Area” with git add. • The staging area is the sum of all changes that will become the next snapshot in time after a “commit”. • git status will now show that the new files is in the staging area (“Changes to be committed”) ☃ The Staging Area (oder “Index”) is a Blob in .git/index
  • 18.
    Local Repository Create commits •So add all changes that will create one coherent snapshot in time (called a “revision”) to the staging area. • You can add as many files at any time you want. • Using git commit the content of the staging area becomes a commit. • Each commit has a description that we can use later to remember what it was all about.
  • 19.
    Local Repository Timeline • Thetime line (git log) now shows the first commit. • Now its time for a few further changes to the Repo: • Lets create a second file called “github.txt” and stage it. • Lets also add a few lines to “cliqz.txt” and also stage this. • Now commit both changes.
  • 20.
    Local Repository So whatsin a commit? • Each revision has these attributes on top of the description: • A unique identifier called SHA1 (its actually a checksum) • Author: Name and e-mail • Time and date of creation • List of files that were changed in this commit ☃ The SHA1 really is formed from the diff itself
  • 21.
    Local Repository Working copyand time travel • Using the SHA1 of a revision you can turn your working copy into its state of the repository • This process is called a Checkout and can be achieved with git checkout. • In ST you double click on a revision • You can’t easily change this resurrected revision (its complicated)!
  • 22.
    Local Repository Branches • Wemight all work on different tasks (“Hey can you fix this quickly?”) • So we need different lines of development (“heads” or “branches”) • Each repository initially has a branch called “master”. It’s the parent of all branches. • Every time you start working on a feature that won’t be finished in a day it’s a good idea to create a branch
  • 23.
    Local Repository Branches, Tags •The working copy can be switched between branches at any time provided that you don’t have uncommitted files that would be changed by the branch switch • It’s always a good idea to check which branch is active before you start working! • It is also possible to bring changes you make to one branch onto another at a later time, but it’s a little bit of work. • Tags are labels you can attach to a certain commit (not to a branch)
  • 24.
    Local Repository Zusammenfassung • Repositoriessave snapshots in time (“revisions”) of a folder (“working directory”) with all its contents. • Changes to these contents can be “staged” at any time. All staged changes are “committed” together with a comment and form a new revision. • You can have different “branches” of development and switch between them. • The working directory can be turned into any revision or branch.
  • 25.
    Schedule • Why? ✔ •GitHub ✔ • Local git Repository ✔ • Collaborating ◀ • First aid
  • 26.
    Collaborating Pushing and pulling •Up to now we only looked at working with a repository on your own computer (and yes, using git can make sense here too). • But the main reason to use a version control system is to easily work on the same set of files in a team without overwriting changes other people made. • We can “push” the changes we make to others • And we can “pull” the changes other team members have made to the files
  • 27.
    Collaborating Workflow • Workflow: Pullfrom upstream, push to origin
  • 28.
    Repositories teilen Eigenes Repositoryzu Server • Anwendungsfall: Eigenes Repo, mit dem bisher nur lokal gearbeitet wurde mit anderen teilen. • Wenn man dazu das eigene Notebook nicht immer angeschaltet lassen will braucht man einen Server :) • Dafür richtet ein Admin ein komplett leeres Repo ein. • Dort kann man dann das gesamte Repo rein schieben • Für den Workshop haben wir für jeden ein leeres Repo auf Martins Notebook angelegt. • Die URL dieses Repos ist ssh:// repo@IP/repo/USERNAME.git, also für Kevin ssh://repo@IP/repo/ kread.git • Schreibt euch diese URL erstmal auf :)
  • 29.
    Repositories teilen Remotes • Wennwir unser Repo jetzt in ein leeres Repo auf Martins Notebook pushen wollen müssen wir besagtes Notebook erstmal als “Remote” anlegen. • Ein Remote ist ein “befreundetes” Repository, mit dem wir Commits teilen. Remotes haben einen Namen und eine URL • Legen wir ein Remote namens “notebook” mit der URL von vorhin an
  • 30.
    Repositories teilen Eigenes Repositoryzu Server Quellrepo Zielrepo Nach einem Push sieht das so aus:
  • 31.
    Repositories teilen Push • EinPush sorgt dafür, dass der Branch im Ziel-Repository (fremdes) auf den selben Commit zeigt wie der gleiche Branch im Quell-Repository (eures). • Dazu werden alle Commits kopiert, die nötig sind, damit die Timeline auf beiden Repos gleich ist. • Wenn das Ziel-Repo leer ist wird also einfach alles kopiert. • Wenn das Ziel-Repo schon Commits hat schaut git nach dem frühesten Commit, den beide gemeinsam haben und kopiert Commits ab da. • ☃ Fortgeschrittene User können mit einem Push alle möglichen abgefahrenen Sachen machen, etwa merges :D
  • 32.
    Repositories teilen Push • Kopierenwir also unseren Branch “master” in das leere Repo des Remotes “notebook” • Das Häkchen bei “Track” (bzw. das “-u”) bedeutet, dass die Branches in beiden Repos sich merken, dass sie nach dem Push identisch sind. • Das spart etwas Handarbeit beim Pullen später, sonst müsste man beim pull immer angeben, aus welchem Remote und Branch gepulled wird.
  • 33.
    Repositories teilen Push • Nachdem Push sehen wir, dass jetzt ein neuer Branch namens “notebook/ master” existiert. • Das ist die Kopie unseres Master- Branches auf diesem Remote. • Mit der Zeit werden beide Branches etwas auseinander laufen. Lets do this! • Dazu machen wir einen weiteren Commit in unseren Master. • ST bzw git status zeigt an, dass unser Branch vor dem Remote ist Pushed nun die neue Änderung zum Remote
  • 34.
    Repositories teilen Klonen • Inden meisten Fällen liegt ein Repository schon irgendwo auf einem Server • In diesem Fall wollen wir dieses Repo auf unseren Rechner klonen • Ein Klon kopiert alle Commits, Branches und Tags • Gleichzeitig legt er ein neues Remote namens “origin” an, das auf das ursprüngliche Repo auf dem Server zeigt. Damit kann man schnell Sachen dort hin pushen.
  • 35.
    Repositories teilen Unser ersterKlon • Holt euch von eurem linken Nachbarn die URL seines Repos und klont dieses in einen Ordner auf eurer Platte. • Mit ST auf File/New • Nun legt hier eine Datei namens “hallo.txt” mit einem freundlichen Gruß an und committet diese. • Und dann an das Remote pushen :)
  • 36.
    Repositories teilen Zusammenfassung • Repositorieskönnen ganze Branches in andere Repositories schieben. • Ein bestehendes Repository kann über das Netzwerk / Internet komplett geklont werden. • Jedes Repo ist dabei ein vollständiges Repo mit Branches und Arbeitskopie. • Mit jedem Repo kann komplett unabhängig gearbeitet werden!
  • 37.
    Fahrplan • Warum? ✔ •Lokales Repository ✔ • Repositories teilen ✔ • Fremde Änderungen einpflegen ◀ • Erste Hilfe
  • 38.
    Fremde Änderungen einpflegen Konfliktpotential •Ihr habt das Repo vom linken Nachbarn auf Martins Notebook verändert und eure Änderungen gepushed. • Wenn euer linker Nachbar zwischenzeitlich keine Commits gemacht hat kann er euren Commit sehr einfach bei sich einspielen. • Hat er jedoch zwischenzeitlich auch Änderungen gemacht kann es zu Konflikten kommen. • Selbst ohne Konflikte gibt es zwei unterschiedliche Timelines. Es gibt verschiedene Strategien, wie diese wieder zusammen geführt werden können.
  • 39.
    Fremde Änderungen einpflegen Konfliktpotential •Nehmen wir den einfachen Fall. • Auf eurem eigenen Repo aktualisieren wir jetzt nun unsere Information über alle Branches auf unserem Remote. • Zur Erinnerung: Euer Remote ist auf Martins Notebook, das euer rechter Nachbar gerade geändert hat. • ST macht das von selbst, auf der Konsole genügt git fetch und dann git status
  • 40.
    Fremde Änderungen einpflegen Commitsholen • git weiss jetzt, dass der master- Branch auf remote aktueller ist als der eigene “master”. • Wenn wir diese Commits auch bei uns haben möchten, brauchen wir git pull • ☃ Ein git merge genügt nicht, da ein git pull mehr ist als ein git fetch; git merge (zB wenn in einem Commit nur ein Branch auf einen andere SHA1 zeigt)
  • 41.
    Fremde Änderungen einpflegen Fast-Forward! •Das Ergebnis ist, dass “master” und “notebook/master” wieder auf den gleichen Commit zeigen - wir sind up-to-date. • Dies ging jetzt nur so einfach, weil zwischenzeitlich nichts am eigenen Repo geändert wurde. “master” hier ist also ein Vorfahre von “master” auf notebook. • git kann daher einen “Fast Forward”- Merge machen, also einfach die neueren Commits vor den eigenen rein kopieren. • Schauen wir uns einen komplexeren Fall an.
  • 42.
    Fremde Änderungen einpflegen EchtesSzenario #1 • Bittet euren rechten Nachbarn (der also euer Repo geklont hat) eine Änderung an der hallo.txt zu machen. • Ihr macht gleichzeitig eine Änderung an der wiegsagt.txt. • Ihr committed beide eure Änderung. • Nachbar pusht, ihr macht einen Fetch. • Ihr seht in ST, dass jetzt zwei Heads existieren. • Wenn ihr jetzt pulled, müssen beide Linien zusammen geführt werden.
  • 43.
    Fremde Änderungen einpflegen EchtesSzenario #1 • Mit einem git pull oder dem Pull-Befehl in ST werden die Linien zusammen geführt. • Dazu wird ein so genannter “Merge Commit” angelegt. Dieser hat nicht einen Vorgänger in der Timeline, sondern gleich zwei. • Auf der Kommandozeile wird man auch nach der Commit-Message gefragt. • Pushed diesen Merge Commit und euren eigenen zurück auf notebook
  • 44.
    Fremde Änderungen einpflegen MergeCommits • Merge Commits haben ihre Daseinsberechtigung. • Wenn man zwei echte Branches zusammen führt ist es vorteilhaft wenn man sieht was hier passiert ist. • Aber bei der gemeinsamen Arbeit an einem Branch machen sie nur das Lesen der Historie schwerer. • Stattdessen haben wir uns alle auf rebase geeinigt. Das Beispiel oben ist krass, aber sowas kann passieren!
  • 45.
    Fremde Änderungen einpflegen EchtesSzenario #1 mit Rebase • Also nochmal ran. Euer Nachbar soll noch einmal die Datei hallo.txt verändern, committen und pushen. • Ihr verändert die wiegsagt.txt und committed, dann ein Pull, aber diesmal mit Rebase. • In ST gibt es dafür eine Checkbox, auf der Kommandozeile mit git pull -r • What just happened?
  • 46.
    Fremde Änderungen einpflegen EchtesSzenario #1 mit Rebase • Rebase sucht genauso wie pull bzw. merge den neuesten Commit, den beide branches gemein haben. • Von diesem ausgehend werden die Commits, die auf das eigene Repo gemacht wurden entfernt und in eine Zwischenablage gelegt. • Nun werden die Commits vom Quell-Repo eingespielt. • Danach alle Commits aus der Zwischenablage. • Nachteil: Die Historie wurde geändert. Merke: Kein rebase nach push! • ☃ Frage: Warum?
  • 47.
    Fremde Änderungen einpflegen Problemebeim Zusammenführen • Unabhängig davon, ob merge oder rebase verwendet wird, kann es beim Zusammenführen Probleme geben. • Wenn in beiden Repos dieselben Stellen in den gleichen Dateien verändert wurden, weiß git nicht, welche Änderung jetzt die richtige ist. • Dann kommt der schöne, heißgeliebte Konflikt-Dialog.
  • 48.
    Fremde Änderungen einpflegen EchtesSzenario #2 • Verursachen wir also einen Konflikt. • Dein Nachbar soll die Datei “wiegsagt.txt” öffnen und ganz unten eine Zeile hinzufügen, committen und pushen. • Du fügst auch eine Zeile hinzu und committest. • Wenn du jetzt pullst, wird es einen Konflikt geben, da git nicht weiß welche hinzugefügte Zeile korrekt ist.
  • 49.
    Fremde Änderungen einpflegen SoftSkill : Konflikte • Dateien mit Konflikten werden in ST mit Ausrufezeichen versehen und in git status extra hervorgehoben. • Der Konflikt muss jetzt von einem Menschen von Hand behoben werden. Dazu gleich mehr. • So lange der Konflikt nicht behoben ist kann nicht wirklich committed, gepulled oder sonstwas werden. • Konflikte beim rebasen verhalten sich etwas anders, aber nicht grundlegend.
  • 50.
    Fremde Änderungen einpflegen EinfacheKonfliktlösung • ST bietet euch einfach die Möglichkeit, den Konflikt in einer Datei zu beheben: • Ihr könnt eure Änderungen oder die Änderungen vom Quell-Repo komplett zu verwerfen. • Dies betrifft nur die Änderungen, die im Konflikt sind, alle anderen veränderten Zeilen der Commits sind ok. • Wird eher selten benötigt.
  • 51.
    Fremde Änderungen einpflegen HändischeKonfliktlösung • Die meisten Konflikte sind komplexer und müssen in der Datei selbst bearbeitet werden. • Öffnet die Datei wiegsagt.txt in eurem Editor. • Der Teil zwischen “===“ und “<<<“ ist üblicher weise die Textstelle, so wie so vom Fremd-Repo kommt. • Von “===“ bis “>>>” die Textstelle, die von euren Commits stammt. • An den Klammern stehen jeweils die Commits, die den Konflikt verursacht haben • Bei rebase steht statt Fremd-Commit “HEAD” (☃ weiß wer warum?) <<<<<<< HEAD Zum Konflikt von Martin ======= Zum Konflikt von Kevin >>>>>>> Von Kevin Fremd-Textstelle Eigene Textstelle
  • 52.
    Fremde Änderungen einpflegen HändischeKonfliktlösung • Entscheidet euch für eine der beiden Textstellen und entfernt die andere. • Oder: Kombiniert beide! • Wenn ihr euch nicht sicher seid was los ist, sprecht mit dem Autor der konfliktverursachenden Änderungen!!!! • Wichtig: Die Zeilen mit <<<, >>> und === müssen mit entfernt werden. • Das Ergebnis kann als konfliktfrei markiert werden. <<<<<<< HEAD Zum Konflikt von Kevin und Martin ======= Zum Konflikt von Kevin >>>>>>> Von Kevin
  • 53.
    Fremde Änderungen einpflegen Nachdem Konflikt • Fügt nun die von euch bereinigte Datei ganz normal zur Staging Area und drückt in ST auf Commit • Auf der Kommandozeile git add gefolgt von git rebase —continue (falls ihr gerade rebased) oder git commit • Ihr könnt in ST auch per Rechtsklick als resolved markieren, das entfernt schon mal die Markierung • Danach natürlich brav pushen.
  • 54.
    Fremde Änderungen einpflegen Zusammenfassung •Es gibt verschiedene Möglichkeiten um Commits in anderen Repos in euer Repo zu bringen. • Rebase ist im Allgemeinen euer Freund, solange ihr nicht einen großen Feature- Branch mergen wollt. • Konflikte von Hand beheben ist schnell gelernt. Ruhig bleiben und tief durchatmen. Im Ernstfall Fat Boy treten. • Bei seltsamen Konflikten im Log herausfinden wer Schuld ist und lieber nachfragen.
  • 55.
    Fahrplan • Warum? ✔ •Lokales Repository ✔ • Repositories teilen ✔ • Fremde Änderungen einpflegen ✔ • Erste Hilfe ◀
  • 56.
    Erste Hilfe Was tunwenns brennt? • Manchmal geht auf einmal nichts mehr (“es geht einfach nicht”), und git verweigert commit, pull, oder push. • Oft gibt es dazu auch eine hilfreiche Fehlermeldung (“Du musst erst pullen bevor du pushen kannst”, “du kannst nicht rebasen wenn du uncommittete Änderungen hast”, …) • Manchmal scheint aber auch einfach alles im Arsch zu sein. • Erste Regel des git-Clubs: Nicht pushen wenn kaputt!!! • Zweite Regel: Keine Panik. Vielleicht helfen euch diese Faustregeln.
  • 57.
    Erste Hilfe Warum gitmanchmal nicht pullen mag • Git hat als oberste Faustregel, dass keine Änderungen verloren gehen dürfen. • Daher mag git auch keine uncommitteten Änderungen überschreiben oder Commits pullen, die eure lokale Historie zerballern würden. • Daher Faustregel: Wenn nicht alles sauber committed ist, könnt ihr nicht pullen und erst recht nicht rebasen. • Committed, nicht gepushed! • Am einfachsten und saubersten ist es, wenn ihr nur Dateien verändert, die zum aktuellen Task gehören und danach alle diese Dateien am Stück committed. • Wenn ihr Dateien geändert habt die nicht zum aktuellen Task gehören, aber die Änderungen sind wichtig, dann einfach zwei Commits machen :) • Wenn auch das nicht geht -> Stash.
  • 58.
    Erste Hilfe Stash it! •Der Stash (englisch für Beutelager) ist ein geheimes Versteck für Änderungen, die ihr zur Zeit nicht committen könnt. • Ihr legt immer alle uncommitteten Änderungen in den Stash und gebt der Sache einen Namen. • Danach ist die Arbeitskopie sauber und ihr könnt pullen etc. • Probiert es aus: wiegsagt.txt ändern, dann git stash save oder in ST
  • 59.
    Erste Hilfe Stash it! •Mit git stash list seht ihr, was sich alles in eurem geheimen Hort befindet, bzw bei ST in der linken Leiste. • Ihr könnt ein Paket an Änderungen zu einem späteren Zeitpunkt aus dem Stash holen und auf den aktuellen Branch anwenden. Der Stash-Eintrag wird dabei auf Wunsche gelöscht (git stash pop) • Danach normal weiter arbeiten und committen. ☃ git stash pop vs apply
  • 60.
    Erste Hilfe Fiese Fremdeinflüsse •Bei Problemen beim Pullen hilft es oft zu schauen, wie die Remotes aussehen, also die Repos, die “befreundet” sind. • Wo ist euer Branch aktuell in der Timeline? Wo derselbe Branch im Remote? Ist HEAD irgendwo seltsam unterwegs? • Wenn das alles nichts hilft und ihr euch sicher seid, dass ihr keine nicht gepushten Commits habt, dann hilft die Radikalkur.
  • 61.
    Erste Hilfe Radikalkur • DieRadikalkur sorgt dafür, dass ein Branch im Repo gestutzt wird. • Die Spitze des Branch wird auf einen bestimmten Commit oder Branch gesetzt, und alles dahinter wird verworfen. • Am häufigsten wird damit das eigene Repo auf den gleichen Stand wie ein Remote gebracht: • git reset —hard REMOTE/ BRANCH
  • 62.
    Erste Hilfe Zusammenfassung • gitverhindert fast immer, dass Änderungen verloren gehen. • Das sieht dann manchmal so aus, als ob es euch hasst und ärgern will. • Wenn nix mehr geht: stachen • Wenn gar nix mehr geht: git reset • Im Zweifelsfall lieber fragen bei Problemen. Nie pushen!
  • 63.
    git is shit? No,git is it! • Wenn man einige Zeit mit git gespielt hat ist alles nicht mehr so seltsam. • Ein gute grafische App hilft enorm. • Wenn ein Problem dort seltsam aussieht hilft manchmal auch ein git status auf der Kommandozeile. • Ich hoffe, ihr habt was gelernt. • Viel Spaß, wie gsagt!