Git ist eine moderne plattformübergreifende freie Sourcecodeverwaltungs Software. Git ist sehr flexible und kann auch Offline verwendet werden – lokal auf dem Rechner.
Grundbegriffe
Repos
Sourcecode-Speicher mit History
Commits
Schappschüsse des Filesystems
Commit History
Verkettung der Schnappschüsse / Commits
Root Commit
Das allererste Commit
Branches
Verzweigung
Aufbau eines Commits
Filesystem-Schnappschuss (Files und Verzeichnisse)
Metadaten (Name, Datum, Kommentar…)
Zeiger auf das letzte Commit (beim Ersten leer, ansonsten Hashwert des vorhergehenden Commits)
Hashwert (Aus allen Daten des Commits)
Git – Pointers
1)
Head-Pointer
2)
Master-Pointer
Basisfunktionen
Version von Git anzeigen:
> git --version
git config –global user.name “<Name>”
Festlegen des eigenen Namens
git config –global user.email “<Email>”
Festlegen der eigenen Emailadresse
git init <name>
Neues Repo mit <name> anlegen
git status
Überblick über das aktuelle Repo
git add <filename>
Änderung hinzufügen (Staging)
git add .
Alle neuen Änderungen übernehmen
git commit -m “<Kommentar>”
Commit erstellen
git log
Zeigt History an
git log — online
Zeigt verkürzte History an
git checkout <Hashwert>
Wechselt den Head-Pointer auf den Commit mit dem <Hashwert>
git checkout master
Setzt den Head-Pointer wieder auf den Master Branch
git revert <Hashwert>
Macht den Commit <Hashwert> rückgänging
Anmerkung: Commit Message wird angezeigt, welche noch geändert werden könnte. Standard Editor VIM mit :qa verlassen
git reset –hard <Hashwert>
Abhängen eines Commits aus der History (dangeling)
git branch <name>
Neuer Branch erstellen
git branch
Alle Branch-Pointer anzeigen
git checkout <Branch-Name>
Wechselt in den angegebenen Branch
git merge <Branch-Name>
Führt einen merge mit dem <Branch-Name> durch
Mergen – “fast-forward”
git checkout master
git merge <Branch-Name>
Visialisierungen mit GitViz
Arbeiten mit Git Remote-Server
Push
Übermittelt lokale Änderungen auf den Server
Fetch
Holt Änderungen vom Remote-Server ab
Pull
Holt Änderungen vom Remote-Server ab und integriert diese im eigenen Code
Clone
Erstellt eine Kopie auf dem lokalen PC
git clone <URL_Repo>
Erstellt eine lokale Kopie des Repos (Bsp: https://github.com/Readify/GitViz.git)
git remote –verbose
Zeigt den verwendete Kurzname / URL des Repos an (Meist: origin)
git push
Übermittelt die lokalen Commits zum Remote-Server
git pull
Holt alle Änderungen vom Remote-Server und merged diese ins lokale Repo
Im Beispiel unten, sehen wir ein Repo mit verschiedenen Git-Pointers:
HEAD -> Master enthält Änderungen, welche remote noch nicht vorhanden sind
Die Pointers “origin/master” und origin/HEAD sind lokal und remote identisch
Es gibt einen Branch “origin/netcore”
Es gibt einen Tag 1.0.2.0
Konflikt zwischen Server und lokalem Repo korrigieren
git status -> zeigt an wo die Probleme sind
Problem in den Dateien beheben -> werden durch Kommentare von Git hervorgehoben
git add <Dateiname> -> Änderungen korrigiert
git commit -m “<Bemerkung>”
git push -> Konsolidierte Dateien auf remote Server übertragen
Remove final attribute from the class to inheriting
Change the visibility from the instance attribute to protected
To inheriting a class do:
CLASS <name> DEFINITION
INHERITING FROM <class_to_inheriting_from>.
Abstract Class
Define a base class as abstract
Sonstiges
lv_text = TEXT-t01 && | | && lv_text.
Space character in a text
&& | | &&
TEXT-<xxx>
Textsymbol
*
Comment out a line
CLASS <name> DEFINITION ENDCLASS.
Interface
CLASS <name> IMPLEMENTATION ENDCLASS.
Class object
CLASS IMPLEMENTATION INHERITING FROM <class_name>. ENDCLASS.
Inheriting
METHODES: show_details REDEFINITION.
Overwriting an inheriting methode
super->show_details( ).
Call the methode in the superclass
TRY. lcl_start=>run ( ) . CATCH cx_root INTO lcl_start=>mo_error. ENDTRY.
Unhandled exceptions cause short dumps
1
Paket
2
Unterpaket
3
Globale Klassen eines Unterpaketes
4
Programme (Reports) eines Unterpaketes
5
Program (Report) mit Klassen, Felder usw.
Prüfen, aktivieren und ausführen
ABAP Unit / Test Classes
CLASS lcl_test DEFINITION
FOR TESTING
DURATION SHORT
RISK LEVEL harmless.
PRIVATE SECTION.
DATA: lo_test TYPE REF TO zcl_main "class under test
METHODES: setup, teardown "Fixture methodes
METHODES: test_method1 FOR TESTING "Test method
ENDCLASS.
FOR TESTING
mark as an unit test class
DURATION
SHORT MEDIUM LONG
RISK LEVEL
HARMLESS (no changes to data or settings) DANGEROUS (date may changed) CRITICAL (data or settings may be changed)
Das Product Backlog ist der Schreibtisch, das Product Owners, welches immer aktuell und sauber geführt werden muss. Es ist eine priorisierte Liste mit Anforderungen / Requirements. Es besteht aus den User Stories, welche eine Anforderung in einem Satz erklären, den Akzeptanzkriterien, Schätzung der Komplexität und den Epics (Grosse Anforderungen, welche noch in User Stories aufgeteilt werden müssen)
DEEP- Kriterien
Detailed Appropriately (angemessen detailiert)
Estimated (geschätzt)
Emergent (mehr als eine Summe der Einzelteile)
Prioritized (priorisiert)
User Stories
INVEST-Kriterien:
Independent (unabhängig)
Negitiable (verhandelbar – veränderbar bis in Sprint Backlog aufgenommen)
Valueable (werthaltig)
Estimable (schätzbar)
Small (klein genug)
Testable (testbar)
Akzeptanzkriterien
Was muss sonst noch beachtet werden (Filterung, Sortierung…)
Gemeinsame Vorstellung / Vision erhalten des Produktes
Wann und wo werden die Stakeholder eingebunden
Risiken, ungefähre Dauer und Kosten
Teamspezifische Aspekte
Arbeitszeiten, Werte, was ist die Projektsprache
Erstellung der
Definition of Done (Wann ist eine Anforderunge Fertig?)
Definition of Ready (Wie muss der Product Owner eine Anforderung beschreiben?)
Organisationsspezifische Aspekte
Schlüsseltermine
Informationen rund um das Projekt
Zusammenkommen mit Stakeholdern
Sprint Planning
Dauer von 1 bis 4 Std.
Formulierung des Sprint-Ziels
Was wird in diesem Sprint Umgesetzt?
Wie viele User Stories können im Sprint umgesetzt werden
Übernehmen ins Sprint Backlog
Benötigte Vorarbeiten:
Vorbereitetes Product Backlog
Vorstellung der Anforderungen (User Stories) durch den Product Owner
Erstellung des Sprint Backlogs
Daily Scrum Meeting
Ist ein Event für das Development Team. Product Owner und Scrum Master sind nicht zwingend erforderlich. Die Praxis zeigt aber, dass es doch empfehlends Wert ist.
Time Box von 15 min.
Jeder beantwortet diese Fragen:
Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint-Ziel zu erreichen?
Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen?
Sehe ich irgendwelche Hindernisse (Impediments), die mich oder das Entwicklungsteam vom erreichen des Ziels abhalten?
Sprint Review
Am Ende des Sprints stellt das Entwicklungsteam die umgesetzten Anforderungen vor. Der Product Owner nimmt die User Stories ab. Der Scrum Master organisiert und moderiert (bei Unstimmigkeiten Entwicklungsteam – Product Owner) das Review.
Wiederholung des Sprint-Ziels
Vorstellung der neu gewonnen Funktionalitäten
Vorstellung der umgesetzten User Stories
Abnahme durch den Product Owner
Bei Abnahme: Anforderung gilt als umgesetzt
Bei Ablehnung durch eine der Begründungen:
Akzeptanzkriterium nicht erfült
Punkt der Definition of Done verletzt
Sprint Retrospektive
Für den Scrum Master ist sie das Herzstück des Frameworks. Im Fokus steht hier die Zusammenarbeit im Team und soll aufzeigen, was noch optimiert oder verbessert werden kann. Es sollen nur Personen aus dem Scrum Team teilnehmen.
Wie gut haben wir Scrum als Framework bereits adaptiert?
Wie läuft unsere Zusammenarbeit?
Was hinder uns, Scrum noch besser zu nutzen?
Folgende Regeln sind Zwingend zu befolgen:
Egal was wir heute erkennen, wir sind fest davon überzeugt, dass alle Beteiligten zu jedem Zeitpunkt nach bestem Wissen, Gewissen und Kenntnisstand gehandelt haben.
Norman Kerth, 2001
Was auch immer in Vegas passiert, bleibt in Vegas.
Vegas-Regel
Sprint
Für den Scrum Master ist die Impediment-Liste das zentrale Artefakt für die allgemeine Organisation des Sprints
Der Scrum Master ist für einen reibungslosen Verlauf des Sprints verantwortlich
Der Product Owner sollte für den Rest des Teams zuallersrt als Ansprechpartner immer zu Verfügung stehen
Das Development Team sollte sich zuallererst während des Sprints Komplett aus sich selbst und sein Sprint Backlog konzentrieren
Dem Product Owner gehört das Produkt, an dem gearbeitet wird. Er trägt die komplette Verantwortung hinter dem Wert des Produktes. Er ist die Schnittstelle zwischen dem Scrum Team und allen anderen Stakeholdern.
Wichtige Punkte:
Mit welchen Anforderungen kann ich den Wert des Produktes für alle Anwender maximieren?
Wann wird das Produkt / Inkrement ausgeliefert?
Scrum Master
Scrum Master ist ein Vorbild beim Scrum Prozess, er ist quasi der Motor des Scrum Prozesses.
Scrum Experte – Muss immer auf dem neusten Stand sein
Change Agent – Bei Einführung von Scrum trägt er eine wichtig Rolle mit
Facilitator – Kümmert sich um alle Probleme im Team und löst diese
Prozesswächter – Überwacht den Prozess / Rahmen – Events müssen korrekt durchgeführt werden
Coach – Moderiert, führt Gespräche
Development Team
Ist eigenverantwortlich für die Umsetzung des vom Product Owner gesetzten Anforderungen. Es muss für die Umsetzung alle benötigten Kompetenzen besitzen – es muss crossfunktional sein.