O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Einführung in git scm

241 visualizações

Publicada em

Kurze Einweisung in Sourcecode Management mit GIT

Publicada em: Software
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Einführung in git scm

  1. 1. GIT Einführung in das SCM System und seine Workflows
  2. 2. Thorsten Körner tvidoo commerce Software Architekt @ThorstenKoerner | https://www.linkedin.com/in/thorstenkoerner
  3. 3. Sourcecode Management Systeme • CVS • Bitkeeper • Subversion • Mercurial • ...
  4. 4. Sourcecode Management Systeme GIT
  5. 5. Sourcecode Management Systeme • Zentrale Systeme • Dezentrale Systeme GIT ist ein dezentrales SCM
  6. 6. GIT SCM $> mkdir myproject $> cd myproject $> git init ... it‘s that easy 
  7. 7. GIT SCM Neues Verzeichnis .git mit Konfigurations und Meta-Informationen über das Repository inclusive der History.
  8. 8. GIT SCM
  9. 9. GIT SCM $> echo “GIT Test“ > README.md
  10. 10. GIT SCM
  11. 11. GIT SCM $> git add README.md $> git status $> git commit –m ‘initital commit‘ $> git status
  12. 12. GIT SCM
  13. 13. GIT Workflows Einfaches arbeiten in großen Teams
  14. 14. GIT Workflows • Arbeiten in Teams • Konflikte bei konkurrierenden Zugriffen • Wie vermeiden? • Branches anlegen
  15. 15. GIT Workflows GIT Branches anlegen • Master Branch nicht für Entwicklung verwenden • Entwicklungs-Branch anlegen $> git checkout –b develop
  16. 16. GIT Workflows
  17. 17. GIT Workflows Weitere Branches nach Bedarf anlegen: z.B. • Feature Branches • Bugfix Branches • Realease Branches • Hotfix Branches • Support Branches
  18. 18. GIT Workflows Viel Arbeit so‘n Zeugs??? Da gibt‘s was fertiges von Ratiopharm 
  19. 19. GITFLOW Fertige Macros für die Schmutzarbeit
  20. 20. GITFLOW
  21. 21. GITFLOW
  22. 22. GITFLOW
  23. 23. GITFLOW Neuer Feature Branch angelegt Branch Namen sollten Konventionen folgen (z.B. incl. Ticket Nr. etc.)
  24. 24. GITFLOW
  25. 25. GITFLOW Wie Feature Branches zurück-integrieren? $> git flow feature finish
  26. 26. GITFLOW
  27. 27. GITFLOW Selbe Vorgehensweise bei: • neuen Features, • bei Bugfixes, • bei Hotfixes • und bei Releases.
  28. 28. GITFLOW Besonderheit bei Hotfix Branches: ‚git flow hotfix finish‘ merged in den Master und Develop Branch gleichzeitig. Kein Vergessen des Merging in den Develop mehr.
  29. 29. GIT SCM Alles auf meinem Rechner? Dezentral? Wie soll denn das mit einem Team funktionieren?
  30. 30. GIT SCM Ein Repository soll das „offizielle“ sein. Das Repository, auf dem alle Fäden zusammenlaufen. Welches?
  31. 31. GIT SCM Jedes Repository auf jedem Rechner kann es sein. Man muss es nur erreichen können: • file:// • http:// https:// • ssh:// • ...
  32. 32. GIT SCM Idealerweise ein Server, der immer und von überall erreichbar ist. Projekte von werden zunächst in eigenes Repository geklont: $> git clone myproject
  33. 33. GIT SCM
  34. 34. GIT SCM
  35. 35. GIT SCM Git clone legt ein neues Repository als exaktes Abbild des „offiziellen“ an. • Alle Dateien • Alle Commits • Komplette History
  36. 36. GIT SCM Wenn wir doch aber schon andauernd comitted haben, ohne dieses “offizielle“ Zeugs, wie sollen unsere Änderungen denn jetzt in dieses Repository gepushed werden? Genau so: Sie werden gepushed. $> git push origin develop
  37. 37. GIT SCM
  38. 38. GIT SCM
  39. 39. GIT SCM
  40. 40. GIT SCM In Git kann man für alle Gelegenheiten Tags vergeben
  41. 41. GIT SCM
  42. 42. GIT SCM
  43. 43. GIT SCM Tags werden normalerweise nicht mit gepushed. Daher muss dies extra angegeben werden.
  44. 44. GIT SCM
  45. 45. GIT WORKFLOWS 2 Noch ein paar Worte zu Workflows in unterschiedlichen Team-Strukturen
  46. 46. GIT WORKFLOWS Klingt alles toll! Aber ist das wirklich der Weisheit letzter Schluss? Klare Frage, klare Antwort: Nein!
  47. 47. GIT WORKFLOWS Das Hauptproblem bei dieser Vorgehensweise ist, dass jeder Entwickler seinen Code in das “offizielle“ Repository merged.
  48. 48. GIT WORKFLOWS Statt dessen: • Feature-Branches mit pushen • Nur lokal finishen, wenn Review und Integration fertig sind.
  49. 49. GIT WORKFLOWS Und wie dann weiter??? Reviewer schauen sich den Code an Tester testen das neue Feature und die Integration Und dann?
  50. 50. GIT WORKFLOWS Ja am Ende muss das Zeugs dann ja doch integriert werden. Das machen aber nicht die Entwickler, sondern dies wird von Integratoren erledigt. Wie passiert das?
  51. 51. GIT WORKFLOWS Die Tester haben irgendwann grünes Licht für die Integration gegeben. Sie erstellen nun einen sogenannten Pull-Request. Integratoren z.B. im Ops-Team schauen sich den Pull-Request an und integrieren diesen in den Develop Branch.
  52. 52. GIT WORKFLOWS Zwei Arten der Integration: • Merge • Rebase
  53. 53. GIT WORKFLOWS Beim mergen bleiben die Verzweigungen erhalten. Wenn man sich den Graphen anschaut, erkennt man sog. Diamantenketten.
  54. 54. GIT WORKFLOWS Mit git rebase zieht man den Graphen glatt und hält ihn übersichtlicher.
  55. 55. GIT WORKFLOWS Achtung: Auch beim Rebase werden Feature Branches & Co. nicht gelöscht, sie tauchen nur nicht mehr direkt im Graphen auf.
  56. 56. GIT SPECIALS Nun noch ein paar erstaunliche Gimmicks von GIT
  57. 57. GIT SPECIALS Gimmick #1: die bisektionale Fehlersuche Wenn ein Feature buggy ist, von dem man weiß, dass es funktionierte, kann man git-bisect verwenden um den Commit zu finden, in dem der Fehler sich eingeschlichen hat.
  58. 58. GIT SPECIALS • Hier startet man eine Suche, der man einen sicher fehlerfreien und einen sicher fehlerbehafteten Commit übergibt. • Zuvor hat man einen kurzen Test geschrieben, der den Fehler identifizieren soll. • Dieser darf natürlich nicht dem Repository hinzugefügt werden, da er sonst in früheren Commits fehlt.
  59. 59. GIT SPECIALS $> git bisect start $> git bisect bad $> git bisect good 3dae9f3e0c
  60. 60. GIT SPECIALS Mit $> git bisect run myTest.sh Wird jetzt die bisektionale Fehlersuche gestartet
  61. 61. GIT SPECIALS • Zunächst wird git-bisect den Commit testen, der in der Mitte zwischen Good und Bad liegt. • Liegt in diesem Commit der Fehler ebenfalls vor, wird die Mitte zwischen diesem Commit und dem als Good markierten Commit getestet usw. • Bis der Commit, der den Fehler eingeschleppt hat identifiziert ist.
  62. 62. GIT SPECIALS Gimmick #2: GIT Submodule Große Projekte weiter strukturieren
  63. 63. GIT SPECIALS Software Teile in eigene Module auslagern. Im Haupt-Repository mit $> git submodule add /sub/module/path/or/url modules/sub einbinden und mit $> git submodule init In der config registrieren.
  64. 64. GIT SPECIALS Es ensteht hierbei eine Datei .gitmodules Diese muss mit $> git add .gitmodules in den Stage hinzugefügt und dann ebenfalls comittet werden.
  65. 65. GIT SPECIALS Alle Submodule werden zunächst am HEAD ausgecheckt. Man kann aber bestimmte Versionen, Tags oder Commits auswählen.
  66. 66. GIT SPECIALS Gimmick #3: Mit git-blame herausfinden, wer in einer Datei welche Teile bearbeitet hat und ob diese Teile aus anderen Dateien kopiert wurden.
  67. 67. GIT SPECIALS
  68. 68. GIT SPECIALS
  69. 69. Vielen Dank fürs zuhören
  70. 70. Thorsten Körner tvidoo commerce Software Architekt @ThorstenKoerner | https://www.linkedin.com/in/thorstenkoerner

×