Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Git Workshop @ Makerspace[A]

Git Workshop @ Makerspace[A]

A74f50459192654b891771cc63e401b6?s=128

Christoph Hochstrasser

August 07, 2019
Tweet

Transcript

  1. Ing. Christoph Hochstrasser Git Workshop MAKERSPACE[A]

  2. Ing. Christoph Hochstrasser Agenda 1. Geschichte 2. Git Begriffe 3.

    Git Grundkonzepte 4. Praktischer Teil 5. Branching Konzepte 6. Do’s and Don’ts 7. Hosting, Forks & Pull Requests
  3. Ing. Christoph Hochstrasser Wozu Git? • „Wer hat was, wann

    & warum am Code gemacht?” • In einer separaten Branch am Code experimentieren und ohne Aufwand wieder verwerfen oder übernehmen • Code anderen Menschen unter einer Open Source Lizenz bereitstellen
  4. Ing. Christoph Hochstrasser Git ist ein DVCS • Distributed Version

    Control System • Es gibt keine Unterteilung in Client und Server (vs. SVN) • Jeder Computer kann ein Repository für andere Nutzende bereitstellen • Alle Nutzenden haben die gesamte Historie und den gesamten Code immer am eigenen Rechner • Server sind einfach Git Repositories, die über SSH oder HTTPS bereitgestellt werden • ALLES kann lokal gemacht werden, es gibt keine Einschränkungen, Server sind nur für Backup und einfachere Zusammenarbeit
  5. Ing. Christoph Hochstrasser Git Geschichte • 2005: BitKeeper kann nicht

    mehr gratis für die Entwicklung des Linux Kernels verwendet werden • 6. Apr 2005: Linus Torvalds kündigt die Entwicklung von Git an • 21. Dez 2005: Git 1.0 wird veröffentlicht • 8. Feb 2008: GitHub wird gegründet
  6. Ing. Christoph Hochstrasser Git installieren • Download für alle Betriebssysteme

    von https://git- scm.org • Enthält nur das Command Line Interface • Keine Installation notwendig bei den meisten Linux Distributionen und allen macOS Versionen • Ein guter GUI Client ist SourceTree von Atlassian (BitBucket)
  7. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Git Begriffe „Everything is

    an Object”
  8. Ing. Christoph Hochstrasser Repository • Besteht aus der Arbeitskopie •

    Besteht aus Commits, Branches und Tags • Kann entweder lokal gespeichert sein oder von einem Server über SSH oder HTTPS bereitgestellt werden, aber grundsätzlich schaut alles gleich aus
  9. Ing. Christoph Hochstrasser Arbeitskopie • Wird verwendet um am eigenen

    Rechner Änderungen im Repository zu machen • Enthält Dateien und Ordner, die am Dateisystem existieren und normal mit Programmen bearbeitet werden können • Kann optional mit anderen Nutzenden geteilt werden, die Pull oder Push machen können
  10. Ing. Christoph Hochstrasser .git • Enthält die Datenbank von Git

    • Größtenteils normale Textdateien, die mit einem Texteditor betrachtet werden können • Enthält alle Änderungen und alle Versionen aller Dateien im Repo • Git ist sehr transparent, es kann sehr viel von außen inspiziert werden, durch Betrachten der Textdateien oder mit einfachen Commands (wie git cat-file)
  11. Ing. Christoph Hochstrasser Object • Grundeinheit in Git, alles ist

    ein Object • ID ist die Prüfsumme des Inhalts (SHA-1, SHA-256) • z.B. „hello world” = 22596363b3de40b06f981fb85d82312e8c0ed511 • Durch Änderung des Inhalts, ändert sich immer die Prüfsumme • Selber Inhalt = Selbe Prüfsumme = Selbes Objekt • „Content Addressable Filesystem” • Üblicherweise genügen die ersten 6–8 Stellen der ID in der Kommunikation oder CLI
  12. Ing. Christoph Hochstrasser Tree • Ordnet die IDs von Objects

    einem Verzeichnisbaum zu, mit Dateinamen und Zugriffsberechtigungen (Unix Modell, z.B. „755”) • Ab dort existiert in Git ein „Dateisystem” • Ist wieder ein Object mit einem SHA Hash, z.B. b701f7c8eaed1d1335e994893cebdf979750d25e
  13. Ing. Christoph Hochstrasser

  14. Ing. Christoph Hochstrasser Index • Änderungen (ja auch einzelne Zeilen)

    werden zum Index hinzugefügt, bevor aus dem Index ein Commit gemacht wird • Kann dazu verwendet werden um Änderungen an der Arbeitskopie wieder rückgängig zu machen • Ein Index ist ein temporärer Tree, der noch nicht durch einen Commit abgespeichert wurde
  15. Ing. Christoph Hochstrasser Commit • Besteht aus einem Tree, einem

    Author, Committer, Timestamp und der Commit Message • Der vorige Commit steht als ID im Feld „parent”, dadurch ergibt sich das Log (auch DAG genannt) — bei einem Merge stehen mehrere Commit IDs im „parent” Feld • Wird wieder als Object gespeichert und bekommt dadurch eine eindeutige ID, die Commit ID • Ein File „HEAD” enthält den aktuellen Commit der aktuellen Arbeitskopie • Eine Textdatei, die so wie die Branch heißt (z.B. „master”) enthält die ID des letzten Commits in der Branch (.git/refs/heads/*)
  16. Ing. Christoph Hochstrasser

  17. Ing. Christoph Hochstrasser

  18. Ing. Christoph Hochstrasser

  19. Ing. Christoph Hochstrasser

  20. Ing. Christoph Hochstrasser Branch • Jedes Git Repository hat standardmäßig

    eine „master” Branch (vgl. mit „trunk” in SVN) • Verzweigung in der Historie • Entsteht aus einer anderen Branch (z.B. master) • Enthält dann Änderungen, die nur in dem Zweig bestehen • Kann entweder gelöscht werden, dann werden alle Änderungen verworfen, oder mit „Merge” können die Änderungen in eine Ziel-Branch übernommen werden
  21. Ing. Christoph Hochstrasser

  22. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Git Grundkonzepte

  23. Ing. Christoph Hochstrasser git config • --local macht Einstellungen lokal

    zum Repository • --global macht Einstellungen für den ganzen Computer • WICHTIG: • user.name • user.email • git config user.name „John” • Aliases können hinzugefügt werden
  24. Ing. Christoph Hochstrasser

  25. Ing. Christoph Hochstrasser .gitignore • Definiert Patterns, für Dateien und

    Ordner, die von Git ignoriert werden sollen, wie /.build oder node_modules • Patterns können auch invertiert werden mit „!”
  26. Ing. Christoph Hochstrasser git clone <url> • Lädt ein Git

    Repository von der URL herunter und erstellt eine Arbeitskopie • BEISPIEL: git clone git://github.com/CHH/php- build • Erstellt eine lokale Arbeitskopie in einem „php- build” Ordner im aktuellen Verzeichnis • Vergleichbar mit „svn checkout”
  27. Ing. Christoph Hochstrasser git init • Legt ein neues lokales

    Git Repository im aktuellen Verzeichnis an • Kann in problemlos in einem Verzeichnis mit bestehenden Dateien & Ordnern gemacht werden • Enthält noch keinen Commit, muss erst mit git add . und git commit gemacht werden • Üblich: git add . && git commit -m „Initial Commit” • Danach kann man den Server hinzufügen, so wie bei GitHub angezeigt (git remote add origin <url>)
  28. Ing. Christoph Hochstrasser (git add|git rm|git mv) <path> • Fügen

    Änderungen (üblicherweise ganze Dateien, aber muss nicht sein) zum Index für den nächsten Commit hinzu • add • Änderungen hinzufügen, handhabt mittlerweile eigentlich umbenannte und gelöschte Dateien automatisch, ein git add . genügt • rm • Datei löschen • mv • Datei umbenennen • Änderungen werden erst beim nächsten Commit gespeichert
  29. Ing. Christoph Hochstrasser git status • Zeigt die Änderungen an

    die zum Index hinzugefügt wurden bzw. die noch nicht hinzugefügt wurden
  30. Ing. Christoph Hochstrasser git commit • Erstellt aus dem Index

    (alle über git add,… hinzugefügten Änderungen) einen Commit • Ohne Argumente wird der Standard-Editor geöffnet (z.B. vim auf Linux) • -m „Nachricht” • -a Einfach alle Änderungen in den Commit übernehmen (ohne git add)
  31. Ing. Christoph Hochstrasser git reset HEAD -- • Schmeißt Änderungen

    die mit git add hinzugefügt wurden wieder aus dem Index raus („Unstage”)
  32. Ing. Christoph Hochstrasser git log • Zeigt die Historie an

    • Hat verschiedenste Optionen um die Historie zu formatieren und darzustellen • -- format=oneline • Ein Commit pro Zeile • -- graph • Baum-Ansicht, praktisch mit Branches • git log <file> • Zeigt alle Änderungen in einer Datei • git log - - author=<author> • Zeigt alle Änderungen einer Person
  33. Ing. Christoph Hochstrasser git stash (pop) • Zwischenspeicher der aktuellen

    Änderungen • Kann mit git stash pop wiederhergestellt werden • Praktisch um Änderungen ohne Commit zwischenzuspeichern, dazwischen einen Pull zu machen und danach wieder weiterzuarbeiten
  34. Ing. Christoph Hochstrasser git branch • Zeigt alle Branches an

    • git branch <branch> • Legt die neue Branch an, basierend auf der aktuellen Branch • git branch -D/-d <branch> • Löscht die Branch
  35. Ing. Christoph Hochstrasser git checkout <branch|tag| commit> • Kann dazu

    verwendet werden um in der Arbeitskopie den Stand eines Commits, Tags oder einer Branch herzustellen • GOTCHA: Nicht verwandt mit svn checkout! • GOTCHA: git checkout . • Setzt die Arbeitskopie auf den letzten Commit zurück • PRAKTISCH: git checkout -b <branch> erstellt eine neue Branch und wechselt gleich dorthin • PRAKTISCH: git checkout - wechselt zurück in die letzte Branch (so wie cd -)
  36. Ing. Christoph Hochstrasser git pull <remote> < branch> • Holt

    Änderungen von einem Git Server • Üblicherweise heißt die Remote „origin” • Führt standardmäßig einen Merge mit der aktuellen Branch durch
  37. Ing. Christoph Hochstrasser git push <remote> <branch> • Speichert die

    Änderungen der Branch auf den Git Server • Wenn es auf dem Server Änderungen gibt, die noch nicht durch einen Pull abgerufen wurden, dann wird ein Fehler zurückgegeben • Beim ersten Push auf einen Server: • git push --set-upstream <remote> <branch> • Dann kann einfach nur „git pull” oder „git push” gemacht werden, ohne Angabe von Branch
  38. Ing. Christoph Hochstrasser git push origin :<branch> • Damit kann

    eine Branch vom Server gelöscht werden • Wichtig: Branch kann nicht wiederhergestellt werden, bleibt aber lokal bestehen! • Lokale Branch kann mit git branch -d gelöscht werden
  39. Ing. Christoph Hochstrasser git merge <branch> • Macht einen Merge

    von <branch> in die aktuelle Branch • Wenn Konflikte entstehen, dann Konflikte beheben und die Datei mit git add <file> hinzufügen • Dann git merge --continue, bzw. git commit am Ende des Merges
  40. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Praktischer Teil

  41. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Git Repo anlegen

  42. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser gitignore

  43. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Erste Files hinzufügen

  44. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Erster Push

  45. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Push & Pull

  46. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Branches

  47. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Rückgängig machen

  48. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Merge

  49. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Push & Pull

  50. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Stash

  51. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Log

  52. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Branching

  53. Ing. Christoph Hochstrasser GitHub Flow • Eine Branch pro Feature,

    beginnt üblicherweise mit kann auch mit Prefix erfolgen „feature/*” • Wird angelegt, wenn mit dem Feature begonnen wird • Wenn das Feature fertig entwickelt ist, dann wird ein Pull Request auf „master” gemacht • Code Review • (Deploy auf Production) • Merge des PR
  54. Ing. Christoph Hochstrasser git-flow • master • hotfix/fix-always-hot-dog • release/v0.0.1

    • development • feature/ml-hot-dog-detection
  55. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Do’s & Don’ts

  56. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Don’t Binäre Dateien ohne

    Zusatz-Tools mit Git versionieren
  57. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Do Git LFS (Large

    File Storage) für große binäre Dateien, wie Office, Bilder, PDF, Binaries verwenden
  58. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Don’t Pull & Merge

  59. Ing. Christoph Hochstrasser

  60. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Do git pull --rebase

    wenn in einem Team gearbeitet wird
  61. Ing. Christoph Hochstrasser

  62. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Don’t Dependencies einchecken

  63. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Hosting, Forks & Pull

    Requests §
  64. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Hosting

  65. Ing. Christoph Hochstrasser GitHub • Größter Hosting Dienst für Git-Repositories

    • Fast alle Open Source Repositories sind auf GitHub • Gehört seit 2018 zu Microsoft • Erfinder der „Pull Requests” und der „Forks”
  66. Ing. Christoph Hochstrasser GitHub Features • Repository Hosting • Projektmanagement

    • Issues • Boards • Wikis • Pull Requests • Forks
  67. Ing. Christoph Hochstrasser BitBucket • Weiterer Hosting Dienst, gehört zu

    Atlassian (Jira, Confluence) • Unbegrenzte private Repositories • Repositories, Issues, Wikis, Forks, Pull Requests
  68. Ing. Christoph Hochstrasser Azure DevOps • Unbegrenzt private Projekte für

    maximal 5 Personen • Continuous Integration ist integriert (auch Windows und macOS verfügbar, z.B. um eine iOS App zu bauen) • Wikis, Pull Requests • Azure Boards ist vergleichbar mit Jira
  69. Ing. Christoph Hochstrasser Remote • Ein Git Repository auf einem

    Host ist ein Remote • Kann mit „git remote” eingestellt werden • git remote add • git remote set-url • Danach ist ein git push und git pull möglich
  70. Ing. Christoph Hochstrasser Authentifizierung • Git sieht keine Authentifizierung vor

    • Historisch entwickelte sich SSH Public Key • Linux, macOS kein Problem • Neuere Möglichkeit ist HTTPS • Funktioniert auf Windows besser • Die Anbieter leiten durch den Prozess
  71. Ing. Christoph Hochstrasser

  72. Ing. Christoph Hochstrasser Ing. Christoph Hochstrasser Pull Requests

  73. Ing. Christoph Hochstrasser Forking • Durch das Klicken auf „Fork”

    wird eine Kopie des Repositories im eigenen Account erstellt • Es besteht danach eine Beziehung zwischen den beiden Repos • Dort können dann in einer Branch Änderungen gemacht werden, wie wenn es das eigene Repository wäre • ACHTUNG: Ein Fork auf GitHub/BitBucket ist kein „Fork” im ursprünglichen Open Source Sinn, es geht nur um den Code!
  74. Ing. Christoph Hochstrasser Pull Requests • Wird dazu verwendet um

    Änderungen, die in einem Fork oder in einer Branch gemacht wurden, jemandem zum Merge vorzuschlagen • Die Empfänger können den Pull Request annehmen und den Merge machen oder den Pull Request ablehnen
  75. Ing. Christoph Hochstrasser Weitere Ressourcen • GitHub Learning Lab •

    Git Book • Git Reference • GitHub Cheat Sheet
  76. Welche Fragen habt ihr?

  77. christoph@hochstrasser.io Wenn dir noch eine Frage einfällt: