SAP Schulung | Österreich und Deutschland

SAP Schulung | Österreich und Deutschland

SAP Schulungen 

Wissensaufbau und Weiterbildung sind wichtig! Möchtet ihr euch zum Thema SAP Cloud weiterbilden oder SAP Fiori/ SAPUI5 lernen? Unsere Kurse sind im offiziellen SAP-Schulungskatalog zu finden. Sei virtuell oder vor Ort im Schulungszentrum mit dabei!

Welche SAP Schulungen gibt es?

SAPUI5/SAP Fiori, SAP Cloud Integration und SAP Cloud Security waren dabei die wichtigsten Themen. Daraus haben wir praxisrelevante Trainings entwickelt. Unser Motto lautet „Von Experten für Experten“.  Mit unseren Trainings haben wir auch die SAP überzeugt und es damit geschafft in den offiziellen SAP Schulungskatalog aufgenommen zu werden. Die Trainings werden organisatorisch und kommerziell von SAP abgewickelt. Unser Anspruch an uns selbst lautet mit „Top Experten und aktuellen Themen“ Kunden überzeugen. Wir stellen die Trainer und aktualisieren laufend unsere Trainings. Unsere Trainer gehören zu den weltweit am besten bewerteten. Vor und nach jedem Training werden die Unterlagen aktualisiert. Unser Kurse finden in Österreich und Deutschland statt sowie aus dem online LIVE Classroom. Folgende Kurse sind für sie  daraus entstanden:

Wie buche ich meine  SAP® Schulung? 📘

Wenn Sie nun den einen Kurs buchen wollen, gehen Sie auf die SAP Homepage https://training.sap.com/. Melden sie sich bitte am System an, danach wählen Sie Österreich und Deutschland aus um die gesamte Auswahl an buchbaren Kursen zu sehen.   Es wurden typischerweise kurze SAP Kurstitel entwickelt: Für  den SAP® UI5 Kurs tippen sie HOUI5 ein. Ausserdem haben wir in unseren SAP® Kurs noch die SAP® Cloud Security mit dem Kürzel WDECPS im Sortiment. Interessiert Sie das Thema SAP Cloud Integration so tippen WDEI1 ein. Wenn Ihre Kursorte erscheinen können Sie auch über den online Live Classroom mit dabei sein. Wir haben hier für sie alle momentanen Kurse und Trainings zusammengefasst. Unser CloudDNA Team freut sich wenn Sie mit dabei sind  und macht Sie fit für ihr SAP Business.

SAP® Schulung HOUI5

Hands-on Foundation zur Entwicklung von SAPUI5 Applikationen

13. März 2023  17. März 2023

SAP® Schulung WDEI1

SAP Cloud Integration – Eine praxisnahe Einführung in Entwicklung und Architektur

SAP® Schulung WDECPS

SAP® Cloud Security – Eine ganzheitliche Betrachtung

6 März 2023  8 März 2023

    F&A

    Welche SAPUI5 /Fiori Schulung ist momentan zu buchen?

    Im Moment bieten wir Hands-on Foundation zur Entwicklung von SAPUI5 Applikationen- Kurstitel HOUI5

    Welche SAP Cloud Schulung bietet Ihr zur Zeit an?

    SAP Cloud Integration – Eine praxisnahe Einführung in Entwicklung und Architektur- Kurstitel WDEI1 ausserdem Cloud Security – Eine ganzheitliche Betrachtung-Kurstitel WDECPS

    Welche Vorteile bieten die SAP Schulungen vom Team der CloudDNA

    Wir bieten 90% Hands on Training von Experten für Experten, aus der Praxis für die Praxis. Unsere Trainer haben selbst die kompletten Trainings ausgearbeitet und können somit alle Fragen mit Präzision beantworten

    Wir freuen uns auf die kommenden Schulungen und Trainings mit Ihnen.

    Möchten Sie mehr über unsere Consulting Packages erfahren : SAP Cloud Connector Setup, SAP CPI OnBoarding, SAP Fiori Quickstart, klicken sie bitte auf den Button:

    Folgen Sie unserem Youtube Channel um keine Neuigkeiten zu verpassen. Wir veröffentlich in regelmässigen Intervallen Videos zur SAP Cloud Platform.

    SAP Trainer Zertifikat 2021 Training Kurs Consultant Clouddna beratung Deutschland Österreich und Schweiz WDECPS WDEI1 HOFIO HOUI5 Fiori Cloud platform Plattform Security Trainer

    CloudDNA Expert Talks zum SAP Cloud Connector

    Sehen Sie sich auch unsere anderen Expert Talks zum SAP Cloud Connector an:

    Grundlagen des SAP Cloud Connector

    Mit Fragen zum Cloud Connector, zu SAP Fiori, zur SAP BTP, SAP Cloud Identity Services, zur SAP Integration Suite und anderen innovativen Themen sind Sie bei uns genau an der richtigen Adresse! Haben Sie Fragen zu unseren Leistungen, Paketen oder Produkten? Kontaktieren Sie uns!

    Ihre Nachricht an die CloudDNA:

    SAP Training | Lerne SAP Fiori / SAPUI5 |SAP Cloud Integration und Security

    SAP Training | Lerne SAP Fiori / SAPUI5 |SAP Cloud Integration und Security

    SAP® TRAININGS der CloudDNA sind im offiziellen SAP Schulungskatalog zu finden!

    Als die Anfrage kam, ob das Team der CloudDNA auch ein SAP Training über SAPUI5/SAP Fiori , SAP Cloud Security und SAP Cloud  Integration entwickeln will. Haben wir uns für sie schnellmöglich an die Ausarbeitung der Kursinhalte gemacht. Aus den letzen Jahren haben wir die Anforderungen aus allen Projekten zusammengetragen. Wir haben mit Kunden gesprochen und ihre Anforderungen erhoben. Ausserdem haben wir für Sie auf das Feedback in Trainings, Schulungen und Lehrgängen gehört.

    SAPUI5/SAP Fiori, SAP Cloud Integration und SAP Cloud Security waren dabei die wichtigsten Themen. Daraus haben wir praxisrelevante Trainings entwickelt. Unser Motto lautet „Von Experten für Experten“.  Mit unseren Trainings haben wir auch die SAP überzeugt und es damit geschafft in den offiziellen SAP Schulungskatalog aufgenommen zu werden. Die Trainings werden organisatorisch und kommerziell von SAP abgewickelt. Unser Anspruch an uns selbst lautet mit „Top Experten und aktuellen Themen“ Kunden überzeugen. Wir stellen die Trainer und aktualisieren laufend unsere Trainings. Unsere Trainer gehören zu den weltweit am besten bewerteten. Vor und nach jedem Training werden die Unterlagen aktualisiert. Unser Kurse finden in Österreich und Deutschland statt sowie aus dem online LIVE Classroom. Folgende Kurse sind für sie  daraus entstanden:

    Wie buche ich mein  SAP® Training? 📘

    Wenn Sie nun den einen Kurs buchen wollen, gehen Sie auf die SAP Homepage. Melden sie sich bitte am System an, danach wählen Sie Österreich und Deutschland aus um die gesamte Auswahl an buchbaren Kursen zu sehen.   Es wurden typischerweise kurze SAP Kurstitel entwickelt: Für  den SAP® UI5 Kurs tippen sie HOUI5, ausserdem haben wir in unseren SAP® Trainings noch die SAP® Cloud Security mit dem Kürzel WDECPS im Sortiment. Interessiert Sie das Thema SAP Cloud Integration so tippen WDEI1 ein. Wenn Ihre Kursorte erscheinen können Sie auch über den online Live Classroom mit dabei sein. Wir haben hier für sie alle momentanen Kurse und Trainings zusammengefasst. Unser CloudDNA Team freut sich wenn Sie mit dabei sind  und macht Sie fit für ihr SAP Business.

    SAP® Training HOUI5

     

     Hands-on Foundation

    Entwicklung von SAPUI5 Applikationen

    Unser Kursinhalt:

    • Um die Prinzipien von SAPUI5 zu verstehen,  erklären wir es Ihnen an einigen durchgängigen Beispiel aus der Praxis für die Praxis.
    • Sie lernen das Implementieren von SAPUI5 Applikationen.
    • Trotz der Komplexität von SapUI5, werden sie nach dem Kurs die Konzepte und Umsetzung von komplexen SAPUI5 Applikationen verstehen. Wir bieten 90% Hands on Training für Sie!
    • Wie können sie effizient und zielgerichtet mit der offiziellen SAPUI5 Dokumentation arbeiten?

    Möchten Sie noch mehr Informationen zu dem SAP Kurs erfahren, dann schauen sie gerne auf unsere Offizielle HOUI5 Seite.

    Hier kommen Sie direkt auf die SAP Trainingsseite für den Kurs SAPUI5 , sollte es bei der Anmeldung Probleme geben haben wir für Sie ein Tutorial vorbereitet:

    SAP® Training WDEI1

    SAP Cloud Integration

    Eine praxisnahe Einführung in Entwicklung und Architektur

    Unser Kursinhalt:

    • Wir betrachten die praxisnahen Aspekte in Cloud Integration Projekten um sie zu verstehen.
    • Unsere Inhalte sind gekennzeichnet durch hohe praktische Erfahrungen. Wie bieten für Sie auch hier ein Hands- on Training
    • Ausserdem gehört SOAP, HTTPS, REST, OData, SFTP, Mail, XI, ABAP Proxy, ESR, SAP PO und Groovy Scripts natürlich auch dazu.

    Möchten Sie noch mehr Informationen zu dem SAP Kurs erfahren, dann schauen sie gerne auf unsere Offizielle WDEI1 Seite.

    Hier kommen Sie direkt auf die SAP Trainingsseite für den Kurs WDEI1 , sollte es bei der Anmeldung Probleme geben haben wir für Sie ein Tutorial vorbereitet:

     SAP®Training WDECPS

     

    SAP® Cloud Security

    Eine ganzheitliche Betrachtung

    Unser Kursinhalt:

    • Wir betrachten gemeinsam die SAP BTP (SAP Cloud Platform) Security, nach dem Kurs werden sie alle technischen Grundlagen die wichtig sind verstehen
    • Sie werden die aktuellsten Szenarien, sowohl im Neo als auch Cloud Foundry Stack verstehen.
    • Unsere Inhalte sind für sie gekennzeichnet  und durch hohe praxisrelevante Erfahrungen besonders interessant . Wir bieten auch hier ein Hands-on Training

      Möchten Sie noch mehr Informationen zu dem SAP Kurs erfahren, dann schauen sie gerne auf unsere Offizielle WDECPS Seite.

      Hier kommen Sie direkt auf die SAP Trainingsseite für den Kurs WDECPS , sollte es bei der Anmeldung Probleme geben haben wir für Sie ein Tutorial vorbereitet:

      SAP TRAINING JA – aber keinen passenden Termin gefunden oder sie wollen nicht verreisen.

      Hier gehts zur Lösung:

      F&A

      Welches SAPUI5 Training ist momentan zu buchen?

      Im Moment bieten wir Hands-on Foundation zur Entwicklung von SAPUI5 Applikationen- Kurstitel HOUI5

      Welche SAP Cloud Trainings bietet Ihr zur Zeit an?

      SAP Cloud Integration – Eine praxisnahe Einführung in Entwicklung und Architektur- Kurstitel WDEI1 ausserdem

      SAP Cloud Security – Eine ganzheitliche Betrachtung-Kurstitel WDECPS

      Welche Vorteile bieten SAP Trainings vom Team der CloudDNA

      Wir bieten 90% Hands on Training von Experten für Experten, aus der Praxis für die Praxis. Unsere Trainer haben selbst die kompletten Trainings ausgearbeitet und können somit alle Fragen mit Präzision beantworten

      Wir freuen uns Sie in den kommenden Kursen und Trainings willkommen zu heissen.

      Möchten Sie mehr über unsere Consulting Packages erfahren : SAP Cloud Connector Setup, SAP CPI OnBoarding, SAP Fiori Quickstart, klicken sie bitte auf den Button:

      Folgen Sie unserem Youtube Channel um keine Neuigkeiten zu verpassen. Wir veröffentlich in regelmässigen Intervallen Videos zur SAP Cloud Platform.

      SAP Trainer Zertifikat 2021 Training Kurs Consultant Clouddna beratung Deutschland Österreich und Schweiz WDECPS WDEI1 HOFIO HOUI5 Fiori Cloud platform Plattform Security Trainer

      CloudDNA Expert Talks zum SAP Cloud Connector

      Sehen Sie sich auch unsere anderen Expert Talks zum SAP Cloud Connector an:

      Grundlagen des SAP Cloud Connector

      Mit Fragen zum Cloud Connector, zu SAP Fiori, zur SAP BTP, SAP Cloud Identity Services, zur SAP Integration Suite und anderen innovativen Themen sind Sie bei uns genau an der richtigen Adresse! Haben Sie Fragen zu unseren Leistungen, Paketen oder Produkten? Kontaktieren Sie uns!

      Ihre Nachricht an die CloudDNA:

      Data Binding in SAPUI5

      Data Binding in SAPUI5

      Übersicht

      In diesem Blog werden wir uns mit Data Binding in SAPUI5, Open UI5 und SAP Fiori Apps beschäftigen.

      Die Inhalte werden in unseren SAP Trainings bis ins kleinste Detail behandelt. Diese Trainings laufen unter den Titeln HOUI5 und HOFIO und werden bei SAP im offiziellen Schulungskatalog für Deutschland, Österreich und der Schweiz gelistet.

      Inhalt

      In diesem Blog zeigen wir Ihnen folgende Themen: 

      • Grundlegendes zum Data Binding
      • Databinding Modi
        • One-Time-Binding
        • One-Way-Binding
        • Two-Way-Binding
      • Arten von Databindings
        • Property Binding
        • Aggregation Binding
        • Element Binding
      • Databinding Syntax
        • Binding Pfad
        • Composite Binding
        • Expression Binding
        • Metadata Binding

      Grundlegendes zum Data Binding in SAPUI5

      In SAPUI5 und OpenUI5 können Sie das Data Binding einsetzen, um Daten aus dem Model unter Verwendung von UI-Controls darzustellen. Das ermöglicht Ihnen auch das Aktualisieren und Editieren der Daten direkt im User Interface, dadurch verknüpfen Sie das User Interface mit dem Model.

      Hierfür benötigen Sie folgende zwei Dinge:

      • Ein Data Model (JSON, OData)
      • Eine Bindinginstanz

      Als Data Model verwenden Sie üblicherweise ein JSON- oder ein OData-Model. Das Model hält für Sie die Daten vor und bietet Ihnen Methoden an , um mit dem Server zu kommunizieren. Zusätzlich bietet es Ihnen Möglichkeiten, um Data Bindings programmatisch zu erstellen. Wenn Sie die Methode aufrufen sorgt es dafür, dass eine Binding Instanz für Sie erstellt wird. Die Instanz beinhaltet Informationen zum Binding sowie bestimmte Events. Ein spezieller Event wird getriggert, wenn sich die gebundenen Daten ändern.

      Welche Data Binding Modi im SAPUI5 gibt es?

      Durch die Enumeration „sap.ui.model.BindingMode“ werden Ihnen drei verschiedene Data Binding Modi bereitgestellt. Diese können Sie unter Verwendung der Methode „.setDefaultBindingMode(bindingMode)“ allgemein auf ein Model anwenden. Optional können Sie es über das Property „oBindingInfo.mode“ auch auf einzelne Binding Instanzen verwenden.

      One-Time-Binding – sap.ui.model.BindingMode.OneTime

      Setzen Sie den BindingMode auf „OneTime“, werden die Daten einmalig vom Model gelesen. Ausserdem können Sie nicht manipuliert werden.

      One-Way-Binding – sap.ui.model.BindingMode.OneWay

      “OneWay”-Binding bedeutet, dass die Daten vom Model gelesen und an die View gebunden werden. Die Daten können Sie in der View zwar manipulieren, aber leider können Sie die Änderungen nicht zurück ins Model übertragen. Dieser Binding Modus war für das JSON-Model lange Zeit das Standardverhalten.

      Two-Way-Binding – sap.ui.model.BindingMode.TwoWay

      Möchten Sie in der View Daten manipulieren und die Änderungen automatisch in das Model übernehmen? Dann ist der Binding Mode „TwoWay“ genau das Richtige für Sie. Im Gegensatz zum One-Way-Binding können Sie Daten vom Model zur View und umgekehrt übertragen.

      Arten von Data Bindings in SAPUI5 und OpenUI5

      In SAPUI5 und OpenUI5 gibt es drei unterschiedliche Arten von Data Bindings. Wie sie damit am arbeiten, führen wir im Folgenden Beitrag für Sie näher aus. Im Data Binding müssen Sie immer einen Bindingpfad angeben. Diesen sollen Sie durch ‚{}‘ kennzeichnen

      Je nachdem, ob Sie das Default-Model oder ein Named-Model verwenden, unterscheidet sich dieser Pfad geringfügig.  Wenn Sie ein  Named-Models verwenden wollen, müssen dem Namen der Property noch ein ‚modelName>‘ voranstellen.

      Möchten Sie die Eigenschaft „FirstName“ auf die value-Eigenschaft eines Inputs binden (Property Binding), sieht das, bei der Verwendung eines Default-Models, wie folgt aus:

      Verwenden Sie hingegen ein Named-Model, müssen Sie der Eigenschaft der Modelname voranstellen:

      Property Binding

      Verwenden Sie ein Property Binding, um beispielsweise Daten in einem Formular zu binden. Hierfür müssen Sie in der entsprechenden Eigenschaft (z.B.: text, value, …) einen Binding-Pfad angeben.

      Am Propertynamen vorangestellten ‚/‘ erkenne Sie, dass es sich um einen absoluten Pfad handelt. Das bedeutet, das sich die Eigenschaft „FirstName“ auf der Root-Ebene des Default-Models befindet.

      Aggregation Binding

      Möchten Sie Listen auf ein UI-Control binden, kommt das Aggregation Binding zum Einsatz. Es wird meist in Listen und Tabellen verwendet, dabei müssen Sie auch ein Template angeben. Dieses wird für jedes Element in der Liste geklont. Innerhalb des Templates müssen Sie relative Pfade verwenden, da der Pfad des Aggregation Bindings bereits auf die entsprechende Liste verweisen. Anstelle eines Templates haben Sie auch die Option eine Factory-Function anzugeben. Die definiert, wie die einzelnen Einträge im User Interface dargestellt werden sollen.

      Default-Model

      Named-Model

      Element Binding

      Das Element Binding ermöglicht Ihnen das Binden einzelner Elemente einer Liste auf UI-Controls. Hierbei wird ein sogenannter Binding-Context erzeugt. Die Binding-Pfade müssen Sie immer relativ angeben.

      Dieses SAPUI5 Data Binding können Sie überwiegend in Master-Detail Fiori Apps einsetzen.

      Das Element-Binding können Sie auf folgende Arten umsetzen:

      • Aufrufen der Methode bindElement im Controller
      • Verwenden einer Binding-Property des Controls

      Data Binding Syntax

      Mit einem Binding-Pfad können Sie ein UI-Control auf die Daten des Models binden.  Wenn sie durch das definieren eines Pfades, erstellen Sie einen Binding-Context.

      Composite Binding

      Wenn Sie einen Formatter verwenden, ist es häufig der Fall, dass mehrere Werte an den Formatter übergeben werden müssen. Diese Anforderung können Sie mit einem Composite-Binding umsetzen. In der jeweiligen Eigenschaft (value, text, …) des UI-Control kann das parts-Array, eine Liste paths definieren.

      Welche Arten von Expression Binding gibt es ?

      Mithilfe des Expression-Binding können Sie simple Prüfungen – z.B.: Vergleich von Werten – direkt in der View zur Laufzeit durchführen. Dadurch ersparen Sie sich das Implementieren von zusätzlichen Formatter-Funktionen im Controller.

      Sie können das Expression-Binding auf 2 Arten umsetzen:

      • ‚{=expression}‘: Es wird ein One-Way-Binding verwendet. Sollten sich Werte im Model ändern, wird auch das Binding aktualisiert.
      • ‚{:=expression}‘: Es wird ein One-Time-Binding verwendet. Der Wert wird einmalig ermittelt und anschließend nicht mehr aktualisiert.

      Als expression können Sie beliebige Prüfungen implementieren. Dabei ist die Syntax ähnliche jener in Javascript, jedoch werden nicht alle JavaScript Expressions unterstützt. Innerhalb der Expression greifen Sie auf Modeldaten folgendermaßen zu: ‚${binding}‘ oder ‚%{binding}‘

      Eine Prüfung und entsprechende Anzeige verschiedener Werte sieht wie folgt aus:

      ${binding} VS %{binding}

      Verwenden Sie ‚${binding}‘ wird der Wert automatisch in den Typ der Eigenschaft des Controls konvertiert. Im Falle des Visible-Properties eines sap.m.Input Controls wäre dies der Typ ‚boolean‘. Wenn Sie nicht immer ist diese Konvertierung erwünschen, können Sie diese mit ‚%{binding}‘ umgehen. ‚%{binding}‘ ist eine Kurzform für ‚${path: ´binding´, targetType: ´any´}‘. Den targetType können Sie durch alle Typen, die sap.ui.model.odata.type bietet ersetzen.

      Metadata Binding

      Möchten Sie die Metadata-Eigenschaften wie sap:label, sap:createable, sap:updatable, … in der View abfragen, können Sie dies mit einem Metadata-Binding erreichen.

      Auch hier können Sie zwei Ansätze verwenden.

      Absolute Bindings

      Absolute Bindings sehen folgendermaßen aus:

      /#EntityName/PropertyName/@Attribut

      Relative Bindings

      Nun zeige ich ihnen wie Relative Bindings aussehen:

      /EntitySetName/PropertyName/#@Attribut

      Best-Practice Beispiel zum Data Binding in SAPUI5 mit OData-Model und Two-Way-Binding

      Abschließend hab ich noch für Sie ein kurzes Best-Practice Beispiel vorbereitet. Wir schicken mit Hilfe eines OData-Models und Two-Way-Binding ein Update auf die Details eines Employees.

      Hier können sie folgende Methoden verwenden:

      • hasPendingChanges: Zum Abfragen, ob es Änderungen gibt
      • submitChanges: Mit ‚Save‘ werden Sie die Änderungen ans Backend schicken
      • resetChanges: Mit ‚Discard‘ werden Sie die Änderungen verwerfen

      View:

      Controller:

      Bei unserem Blog über Data Binding in SAPUi5 haben sie nun viele Informationen bekommen. Wenn sie an weiteren Themen interessiert sind, klicken sie hier unten auf GIT oder SAPUI5 Custom Controls. 

      Wollen Sie, dass  wir uns um Ihre Szenarien kümmern? Nehmen Sie gerne Kontakt auf den  klassische SAP Beratung und SAP Cloud Consulting liegt uns .Egal ob Deutschland, Schweiz oder Österreich – unser Team bestehend aus erfahrerenen Beratern und Entwicklern ist gerne für Sie da!

      Wir lassen sie nicht in der Cloud hängen den SAP ( Cloud ) Consulting liegt in unsere DNA

      Git Tutorial | Git Anleitung | Git Wissen | Git erklären Teil 3

      Git Tutorial | Git Anleitung | Git Wissen | Git erklären Teil 3

      Git Repositorys / Branches | Konflikte lösen

      Dieses Git Tutorial macht dich zum Git Profi

      Lernen Sie mit diesem Git Tutorial wie Git Repositories angelegt und in der SAP WebIDE verwendet werden können. Wir erklären Ihnen außerdem wie Konflikte gelöst werden können.

      In der Blogreihe werden wir uns mit dem Thema Git beschäftigen und damit, warum das Arbeiten mit Git oder mit einem ähnlichen Tool für Entwickler fast schon unumgänglich ist.  Möchten Sie mehr über Git wissen oder haben Sie noch mehr Fragen zum Git Tutorial, nehmen Sie gerne Kontakt auf.

      Die folgenden Informationen werden auch, jedoch um einiges ausführlicher, in unseren offiziell bei der SAP im Schulungskatalog gelisteten Kursen HOUI5 und HOFIObehandelt.

      Besuchen Sie unsere SAP Standard Trainings

      Wir haben mit dem HOUI5 und dem HOFIO zwei 5-Tage-Trainings auf höchstem Niveau erstellt! Lernen Sie von uns die professionelle SAPUI5 und SAP Fiori Entwicklung!

      Inhalt des Git Tutorial

      Auf folgende Themen werden wir in unserer Blogreihe eingehen:

      • Einführung in die Welt von Git
      • Begrifflichkeiten und die wichtigsten Funktionen
      • SAPUI5-Entwicklung mit Hilfe von Git
        • Exkurs: LDAP-Anbindung und Git-Server-Anbindung an die SAP Cloud Platform

      Zielsetzung

      Unser Ziel ist es, dass man nach unserem Git Tutorial die unten stehende Grafik interpretieren und mit Git die SAPUI5-Entwicklung optimieren kann.

      Wichtig

      Seitdem GitHub die Namenskonventionen umgestellt hat, heißt der Strang, der automatisch angelegt wird, nicht mehr „master“ bzw. „origin/master“, sondern „main“ und „origin/main“. Da die SAP WebIDE diese Änderung noch nicht erkennt, muss man das entweder in der WebIDE mitgeben oder in GitHub übersteuern.

      Part 3 – Inhaltsverzeichnis Git Tutorial

      1. Repository anlegen (GitHub und SCP)
      2. Git Pane in der WebIDE + die wichtigsten Funktionen
      3. Conflict Handling

      Über den Autor

      Daniel Krancz

      Daniel Krancz

      SAP-Consultant / Software-Developer

      Ich bin SAP-Berater und -Entwickler im SAPUI5/Fiori- und OData-Umfeld. Seit 2019 bin ich offiziell als externer Trainer bei SAP gelistet und halte Kurse (UX, S4, …) über SAP-Webentwicklungen und Cloud-Implementierungen im In- und Ausland. Seit 2021 bin ich SAP Press Autor beim Rheinwerk Verlag im Bereich SAP Mobile.

      Einen letzten Punkt unseres Git Tutorial haben wir noch offen, nämlich die Verwendung von Git bei SAPUI5-Entwicklungen.

      SAPUI5-Entwicklung – Git Tutorial

      Ein jeder SAPUI5-Entwickler wird wahrscheinlich diesen Hinweis beim Importieren von bereits bestehenden SAPUI5-Apps aus dem ABAP-Repository schon mal gesehen haben:

      Auch wenn man sonst noch nie was von Git gehört hat, wird man spätestens an dieser Stelle merken, dass es fast unabdingbar mit Git die Sourcen zu verwalten.

      Aber wenn es um Git geht, stellt die SAP nicht nur diesen Hinweis zur Verfügung, sondern auch einen in die WebIDE integrierten Git Pane zur Verfügung.

      Wie lege ich ein Git Repository an?

      Für unser Beispiel werden wir zwei Git Repositories anlegen, nämlich einmal in GitHub und in der SAP Cloud Platform. Unser Beispielprojekt ist nachher nur mit dem GitHub Repository verknüpft. Im Lizenzmodell für die WebIDE sind auch die Git Repositories in der SAP Cloud Platform inkludiert.

      GitHub

      In GitHub können wir private Repositories anlegen, aber auch Repositories in Organisationen, in denen ich eingeladen worden bin.

      Man hat zurzeit zwei Varianten an Repositories:

      Public Repositories

      • für alle zugänglich, die den Link zur Repository haben
      • jeder kann clonen
      • Schreibrechte kann man einschränken (Push-Requests)

      Private Repositories

      • nur für Sie oder für die Organisation sichtbar (siehe Owner)
      • Innerhalb Ihrer Org. kann man eigene Teams verwalten, die je nach Rolle Lese- und Schreibrechte haben

      Zusätzlich sollte man noch einen README-File anlegen lassen, welche als Startseite für den Repository dient und dem User grundlegende Informationen vom Repo. anzeigen soll.

      Es besteht auch die Möglichkeit, bestimmte Files und Filetypen ignorieren und bekannte Lizenzmodelle hinzufügen zu lassen. (.gitignore)

      Nach dem Klick auf „Create repository“ wird man auch gleich in den Repository Browser geleitet:

      Auf alle einzelnen Möglichkeiten möchte ich hier nicht detailliert eingehen, weil diese Informationen eh schon überall im Internet zu finden sind.

      Kurz zusammengefasst:

      • man kann Lese- und Schreibrechte an bestimmte Personen und Teams vergeben
      • Commits und Pull-Requests verfolgen
      • Auswertungen ansehen
      • in den Einstellungen von Security bis Benachrichtigungen alles einstellen

      Was für uns in Zukunft jetzt wichtig ist, ist der Repository URL. Bei einem Clone müssen wir diese URL angeben, denn diese ist der Zeiger zu unserem Repository:

      https://github.com/clouddnagmbh/blogrepo

      SAP Cloud Platform

      Im Subaccount in der SCP (SAP Cloud Platform) hat man links im Menü die Möglichkeit Repositorys zu verwalten. Wenn Sie diesen Menüpunkt nicht sehen, dann fehlen Ihnen wahrscheinlich die nötigen Berechtigungen.

      Mit dem „New Repository“-Button können wir gleich einen Repository anlegen. Hier ist natürlich wichtig zu wissen, dass die Authentifizierung über die SCP erfolgt.

      Nachdem wir einen Namen und Beschreibung vergeben haben, können wir noch bestimmen, dass unser Repository mit einem initialen leeren Commit angelegt werden soll.

      Wenn wir die Details zu unserer Repository anschauen, dann können wir ein paar Informationen ablesen und direkt auch einige Funktionen ausführen.

      Es besteht die Möglichkeit, wieder den Namen zu editieren, unserem Repository nur Leserechte zu geben, den Garbage Collector zu starten, aber auch unser Repository direkt in die WebIDE clonen zu lassen.

      Zwei wichtige Links sieht man auch gleich, nämlich einen mit dem Zeiger auf unseren Repository (wichtig, wenn man clonen möchte) und einen für den Repository Browser (nichts anderes als ein Explorer).

      Was für uns in Zukunft jetzt wichtig ist, ist der Repository URL. Bei einem Clone müssen wir diese URL angeben, denn diese ist der Zeiger zu unserem Repository:

      https://git.eu2.hana.ondemand.com/<subaccount>/blogrepo

      Entwicklung- Git Tutorial

      In unserer WebIDE können wir an mehreren Stellen einen Git Repository clonen. Anbei eine Möglichkeit:

      Alle Varianten würden im Endeffekt zu diesem Wizard führen:

      Hier müssen wir unsere Repository URL einfügen. Zusätzlich könnte man eine Konfiguration für Gerrit, ein Review-System von Google, hinzufügen.

      Nach einer erfolgreichen Authentifizierung und Clone sehen wir die geclonte Applikation in unserem Workspace:

      Jedoch bringt uns das in unserem Fall noch nichts, weil unser Repository leer ist. Wir haben ja im zweiten Teil unserer Blogreihe gelernt, dass ein Entwickler der Erste sein muss, der quasi eine Rahmenapplikation deployed.

      Also lösche ich vorerst das geclonte Projekt, lege eine neue SAPUI5-App an und mit Rechtsklick auf das Projekt lege ich ein neues lokales Git Repository an:

      In einem Popup kann man den Benutzernamen und die Mailadresse hinterlegen, welche bei den Commits als Author eingetragen wird:

      Der Hinweis, dass das nicht mehr geändert werden kann, stimmt hier nicht ganz. Über Project -> Project Settings -> Git Repository kann das ganze geändert werden.

      Nach dem ich das lokale Git Repository angelegt habe, bekomme ich auch gleich die Information, dass ich einen Remote Repository anbinden soll:

      Das machen wir auch gleich und tragen unseren bereits erstellen Remote Repository ein:

      Da das Ganze im Grunde genommen nichts anderes ist, als das Zusammenführen von Local und Remote Repository, wird zuerst noch ein Fetch gemacht.

      Wir öffnen direkt den integrierten Git Pane:

      Nun können wir hier in einer grafischen Oberfläche verschiedene Funktionen ausführen:

      1. Wie wir im zweiten Teil unserer Blogreihe kennengelernt haben, könnte man hier auf die verschiedensten Funktionen (Fetch, Merge, Pull, …) zugreifen.
      2. Man sieht auf einem Blick um welchen Local Repository es sich handelt und man könnte neue Local Branches erstellen und zwischen diesen wechseln.
      3. Eine Liste der Änderungen seit dem letzten Commit

      Nocht nicht genug ? Weiter gehts ….

      4. Alle Änderungen, die sich im Staging Area befinden, werden auch beim nächsten Commit mitgenommen. Also wenn ich Änderungen habe, die ich noch nicht veröffentlichen will, dann werde ich diese aus der Staging Area rausnehmen und somit beim nächsten Commit nicht mit den anderen teilen.

      5. Jeder Commit erfordert eine Beschreibung, wie zum Beispiel eine kurze Zusammenfassung meiner Änderungen.

      6. Die Möglichkeit für Commit und Push findet man ganz unten.

      Symbole in der WebIDE

      Initial Commit and Push

      Wir haben einen Rahmenprojekt angelegt und sind der erste, der das Projekt auf den Remote Repository pusht:

      Nach einem erfolgreichen Push-Request können wir die Sourcen am Repository Browser ansehen:

      Nehmen wir jetzt an, dass wir diese Applikation nicht erstellt haben. Dann müssten wir genau an dieser Stelle einen Clone in unsere WebIDE vollziehen:

      Bei einem Clone erhält unser Projekt in der WebIDE den Namen vom Remote Repository. Gleich daneben steht auch, auf welchem lokalen Branch wir gerade arbeiten:

      Wie erstelle ich einen Local Branch im Git?

      Im Git Pane haben wir die Möglichkeit zu unserem standardmäßig erstellen „master“ Branch weitere Local Branches zu erstellen.

      Man wählt die Quelle aus (kann auch ein Remote Branch sein) und benennt den zu erstellenden lokalen Branch (in unserem Fall „featureA“):

      Nach dem Erstellen befinden wir uns auch schon direkt in dem Feature Branch. Sie können mit Hilfe des Drop-Downs auch wieder wechseln.

      In unserem Feature Branch machen wir ein paar Änderungen, legen neue Views an und fügen ein Label in die View ein. Wir beschreiben die Änderungen dementsprechend und committen sie:

      Nachdem wir mit unseren Feature Implementierungen fertig sind, möchten wir diese mit anderen Entwicklern teilen. Wir haben in unserem Git Pane einen Indikator, dass wir seit dem letzten Merge einen Commit gemacht haben:

      Nun wechseln wir in den lokalen „master“ Branch und machen einen Merge mit unserem Feature Branch. Wir verbinden die zwei Datenstände miteinander und prüfen auf eventuelle Konflikte:

      Nachdem der Merge (in unserem Fall) ohne Konflikte durchgelaufen ist, checken wir die Sourcen im „master“ Branch und sehen, dass die Änderungen aus unserem Feature Branch in unserem lokalen „master“ Branch gelandet sind:

      Wir hätten unseren Feature Branch natürlich auch gleich mit dem Remote Branch zusammenführen können, aber so konnten wir schonmal sichergehen, dass es mit dem letzten „origin/master“ Branch, welche ja unserem lokalen „master“ Branch entsprochen hat, keine Konflikte gibt.

      Das bringt den anderen Entwicklern jetzt noch nichts. Nun müssen wir diese Änderungen auch auf den Remote Repository pushen. Aber wie wir schon im zweiten Teil unserer Blogreihe gelernt haben, müssen wir vorher checken, ob die anderen auch schon Änderungen gemacht und am Remote Repository gepusht haben.

      Ich bevorzuge an dieser Stelle einen Fetch. In der Zusammenfassung schaue ich mir auch an, ob und was andere Entwickler gemacht haben:

      Wir sehen, dass sich am Remote Repository seit unserem letzten Fetch nichts getan hat, somit können wir beruhigt pushen:

      Wenn wir jetzt in den Browser Repository wechseln, dann werden wir auch sehen, dass dort unsere Änderungen bzw. unsere Feature Entwicklung sichtbar ist:

      Was man hier noch gut sieht ist, dass nur die Deltas ausgetauscht worden sind. Die nicht geänderten Files haben noch immer den letzten Status und auch die letzte Commit Beschreibung, weil wir selbst die anderen Files, auch wenn wir am Projekt was geändert haben, nicht manipuliert haben.

      Wie funktioniert das Conflict Handling mit Git?

      In unserem Fall war das jetzt ganz einfach, da kein anderer Entwickler uns in die Quere kommen konnte. Aber wie ein Konflikt aussehen würde, haben wir hier für Sie simuliert.

      Ich habe mich umentschieden und in meiner WebIDE im Label doch einen anderen Text eingetragen:

      Diese Änderung werde ich jetzt wie gewohnt in die Staging Area bringen und mit einer entsprechenden Beschreibung einen Commit durchführen:

      Wir machen einen Fetch um zu sehen, ob andere Entwickler auch was gemacht haben:

      Da sehen wir jetzt, dass ein anderer Entwickler auch etwas geändert hat. Vorerst kein Problem, das ist ja eine ganz normale Situation, da unser Entwicklungsteam groß ist.

      Was für uns aber neu ist, ist dieser Indikator:

      Das bedeutet wir haben einen Commit seit dem letzten Merge gemacht und auch am dazugehörigen Remote Repo. hat es einen Commit seither gegeben.

      Wir machen jetzt einen Merge, um die zwei Datenstände miteinander zu vereinen und da bemerken wir, dass es Konflikte gibt:

      Ein Klick auf „Resolve Conflicts“ und dann landen wir es in einen grafischen Editor für das Beheben der Konflikte:

      Hier sieht man die zwei Versionen einander gegenübergestellt und auch die Version, die nach unserer Konfliktbehebung entstehen würde.

      Mit den Buttons rechts oben könnten wir auf die Schnelle sagen, ob wir unsere Änderungen oder die Änderungen vom Remote Repo. nehmen möchten. Hinter diesem grafischen Editor steht eigentlich nichts anderes als ein Code mit bestimmten Abschnitten und Markierungen, wo Konflikte aufgetreten sind:

      Also könnte man im grafischen Editor die Konflikte lösen, aber auch im Code. Man würde hier genau diesen Abschnitt rausschmeißen, welchen man als veraltet empfindet.

      Wenn wir alle Konflikte behoben haben, dann bleibt uns nichts anderes mehr übrig, als einen Commit zu machen, je nachdem wie viel Zeit wir für die Konflikten aufgewendet haben, wieder einen Fetch mit Merge zu machen und anschließend unseren Code zu pushen.

      Bei einem Conflict Handling haben wir während dem Beheben auch nicht alle Funktionen zur Verfügung:

      Wir können lediglich einen Fetch machen und uns den aktuellen Stand holen oder die bereits gemachten Änderungen zurücksetzen.

      Nach einem Commit von unserer Fehlerbehebung sehen wir am Indikator, dass wir nun nicht einen Commit vor und auch gleichzeitig nach dem origin/master sind, sondern zwei Commits voraus. Einmal haben wir ja unser Label geändert und einmal einen Merge mit Konfliktbehebung (= erneuter Commit) gemacht.

      Zusammenfassung – Git Tutorial

      Jetzt steht uns nichts mehr im Wege! Wir haben gelernt, wie wir unsere Entwicklungen mit Git optimieren können und in diesem Bereich vor allem das Zusammenarbeiten mit anderen Entwicklern. Der nächste und letzter Teil unserer Blogreihe, nämlich ein Exkurs von Martin Koch verfasst und präsentiert, wird demnächst veröffentlicht.

      Git und SAPUi5
      Git Tutorial 2 |Git Anleitung| Git Wissen| Git erklären Teil 2

      Git Tutorial 2 |Git Anleitung| Git Wissen| Git erklären Teil 2

      Git Tutorial: die wichtigsten Begriffe und Funktionen

      Mit diesem Git Tutorial / Git Grundlagen wirst du zum Git Profi!

      Mit dieser Git-Anleitung möchten wir dir zeigen, wie wichtig Git für Entwickler geworden ist. In dieser Blogreihe werden wir uns mit dem Thema Git beschäftigen und damit, warum das Arbeiten mit Git oder mit einem ähnlichen Tool für Entwickler fast schon unumgänglich ist.

      Die folgenden Informationen werden auch, jedoch um einiges ausführlicher, in unserem – offiziell bei der SAP im Schulungskatalog gelisteten – Kurs HOUI5 behandelt.

      Inhalt des Git Tutorials

      Wir werden auf folgende Themen eingehen:

      • Einführung in die Welt von Git
      • Begrifflichkeiten und die wichtigsten Funktionen
      • SAPUI5-Entwicklung mit Hilfe von Git
        • Exkurs: LDAP-Anbindung und Git-Server-Anbindung an die SAP Cloud Platform

      Zielsetzung

      Unser Ziel ist es, dass du nach dem  Git Tutorial, die unten stehende Grafik interpretieren und mit Git die SAPUI5-Entwicklung optimieren kann.

      Das Video zum Blog

      Wichtig

      Seitdem GitHub die Namenskonventionen umgestellt hat, heißt der Strang, der automatisch angelegt wird, nicht mehr „master“ bzw. „origin/master“, sondern „main“ und „origin/main“. Da die SAP WebIDE diese Änderung noch nicht erkennt, muss man das entweder in der WebIDE mitgeben oder in GitHub übersteuern.

      Git Tutorial Part 2 – Inhaltsverzeichnis

      Begrifflichkeiten:

      1. Repository
      2. Branch
      3. Commit
      4. Staging Area

      Funktionen:

      1. Push
      2. Clone
      3. Fetch
      4. Merge
      5. Pull
      6. Best practice
      7. Rebase
      8. Reset (Hard Reset & Mixed Reset)

      Über den Autor

      Daniel Krancz

      Daniel Krancz

      SAP-Consultant / Software-Developer

      Ich bin SAP-Berater und -Entwickler im SAPUI5/Fiori- und OData-Umfeld. Seit 2019 bin ich offiziell als externer Trainer bei SAP gelistet und halte Kurse (UX, S4, …) über SAP-Webentwicklungen und Cloud-Implementierungen im In- und Ausland. Seit 2021 bin ich SAP Press Autor beim Rheinwerk Verlag im Bereich SAP Mobile.

      Begrifflichkeiten

      Zu einem guten Git Tutorial gehört natürlich auch, dass erklären der wichtigsten Begrifflichkeiten und gängigsten Funktionen im Git-Umfeld.

      Repository

      Ein Repository kann mit einem einfachen Verzeichnis verglichen werden, in welchem weitere Verzeichnisse und Dateien abgelegt werden können. Ein Repository beinhaltet normalerweise ein Projekt bzw. ein Programm.

      Es gibt eine Unterscheidung zwischen einem Remote (am Server oder in der Cloud) und einem Local (in der IDE) Repository.

      Branch

      Ein Repository beinhaltet mindestens einen Entwicklungsstrang, kann aber auch in mehrere Entwicklungsstränge unterteilt werden. Diese Stränge nennt man Branches.

      Branches benutzt man entweder um Systemlandschaften (z.B. DEV, QAS und PRD) oder Feature-Entwicklungen (z.B. eine neue Funktionalität für Kunden) abzubilden. Die Unterteilung in den Landschaften ist üblicherweise am Remote Repository vertreten.

      Je nachdem wo die Branches liegen, redet man von Remote und Local Branches.

      Wenn man ein Remote Repository erstellt, so wird automatisch auch der erste Branch mit dem Namen „origin/master“ angelegt. Bei einem Local Repository heißt der erste Branch nur „master“.

      Commit

      Einen Commit kann man mit einem Snapshot, sprich mit einer Momentaufnahme, vergleichen. Diese Momentaufnahme beinhaltet die gesamten Änderungen seit dem letzten Commit. Diese Commits werden mit bestimmten Daten (Description, ID, Author, Timestamp, …) versehen und abgespeichert.

      Ein Commit ist somit die kleinste „Einheit“ im Git-Umfeld.

      Staging Area

      In der Staging Area befinden sich alle Files, die seit dem letzten Commit editiert wurden. Das heißt, die Staging Area ist ein Ort für das Zwischenspeichern der Änderungen. Zusätzlich kann man auswählen, welche Änderungen aus der Staging Area man beim nächsten Commit mitnehmen möchte.

      So könnte man X Änderungen aus der Staging Area auf Y Commits aufteilen und so einen sauberen Entwicklungsstrang abbilden.

      Wie funktioniert Git, und welche Vorteile hat es für die SAP-Entwicklung?- Alles darüber findet Ihr in diesem Buch: Amazon oder Rheinwerk

      Git und SAP - Versionsverwaltung und Transporte

      Welche Funktionen gibt es in Git?

      Mit diesem Git Tutorial, gehen wir ausserdem auf die gängigsten Funktionen ein, mit der man Repositories und Branches manipulieren kann. Wir werden uns nur die wichtigsten anschauen (Push, Fetch, Merge, Pull, Clone, Rebase), aber es gibt noch um einiges mehr (Cherry-Pick, Stashing, …).

      Push

      Wenn man in der IDE entwickelt und irgendwann einen Stand hat, den man mit anderen Entwicklern teilen möchte, dann muss man den letzten Commit mit einem Push in das Remote Repository bringen.

      Da das Remote Repository am Anfang leer ist, kann der erste Entwickler, der z.B. das Rahmenprojekt aufgesetzt hat, seine Entwicklungen ohne Rücksicht pushen:

      Später sollte vor jedem Push gecheckt werden, ob sich am Remote Repository etwas geändert hat. Wie das funktioniert, erfahren Sie weiter unten.

      Clone

      Es kann nur einen ersten bzw. initialen Push geben. Wenn also sich am Remote Repository bereits Daten befinden, dann muss ich das Ganze in meine lokale Umgebung bekommen.

      Das funktioniert mit einem Clone:

      Fetch

      Mit einem Fetch kann ich die Änderungen, die seit meinem letzten Fetch gemacht wurden, in die lokale Umgebung laden. Einfacher ausgedrückt: Wir schauen nach, ob andere Entwickler was Neues gemacht haben.

      Merge

      Nur nachschauen, ob andere Entwickler etwas gemacht haben, reicht noch nicht ganz aus. Wir müssen die Datenstände zusammenführen und diesen Vorgang nennt man Merge.

      Wir haben vorhin, als wir über Branches geredet haben, etwas verschwiegen. Die Namen für Branches sind nichts anderes wie Pointer bzw. Zeiger. Ein Zeiger auf den aktuellen Commit, sprich auf den letzten Snapshot.

      Was bei einem Merge technisch passiert ist ganz einfach: Der Zeiger von meinem altem Commit, wird auf den neuen Commit gesetzt, welchen wir uns mit einem Fetch geladen haben. Dabei wird geschaut, ob sich Änderungen überschneiden. Wenn sich Änderungen überschneiden, gibt es Konflikte.

      Auf Konflikte wird man immer hingewiesen und der Entwickler, der die Zusammenführung macht, kann entscheiden, welche Code-Passagen die Aktuellen sind. Ein Merge wird in einem eigenen Commit protokolliert.

      Pull

      Man sieht jetzt schon, dass man Fetch und Merge oft brauchen wird. Das haben sich auch die Entwickler von Git gedacht und deswegen die Funktion Pull ins Leben gerufen.

      Pull führt zuerst einen Fetch und dann automatisch einen Merge aus:

      Git Tutorial – Best practice

      Einmalig:

      • Clone or Initial Commit and Push
        • wenn ich der erste bin = Push
        • App vom Remote Repository clonen

      Wiederkehrend:

      1. Fetch: schauen ob sich was getan hat
      2. Merge: den Zeiger auf die aktuelle Version verschieben und die Datenstände zusammenführen (auf eventuelle Konflikte reagieren)
      3. Push: die aktuelle Version mit anderen Entwicklern teilen
      1. Pull: schauen ob sich was getan hat, den Zeiger auf die aktuelle Version verschieben und die Datenstände zusammenführen (auf eventuelle Konflikte reagieren)
      2. Push: die aktuelle Version mit anderen Entwicklern teilen

      Wir kennen jetzt viele Begriffe und kennen auch schon die wichtigsten Funktionalitäten. Jetzt gehen wir nochmal auf die Branches ein und bringen all das Wissen mit, was wir gelernt haben.

      Wir haben gesagt, dass auch am Remote Repository Branches erstellt werden können (z.B. P,Q,D), aber auch am Local Repository (z.B. Features).

      Gehen wir von folgendem Beispiel aus: Es existiert bereits ein Repository und da wir jetzt auch im Entwicklerteam sind, können wir vom Remote Repository vom Entwicklungsbranch die aktuellen Stände clonen.

      Wir machen sicherheitshalber einen Local Feature Branch wo wir einige Entwicklungen und auch Commits machen. Nach einigen Entwicklungstagen sind wir fertig und mergen lokal unsere Features mit dem lokalen Master.

      Bevor wir unsere Änderungen mit anderen teilen können, müssen wir checken, ob andere Entwickler auch zwischenzeitlich gepusht haben und führen einen Fetch und danach Merge bzw. einen Pull aus.

      Nachdem wir uns mit einigen Konflikten beschäftigen durften, können wir nun endlich unsere Änderungen pushen und mit anderen Entwicklern teilen.

      Unser Administrator nimmt nach eigenem Ermessen die Datenstände und macht einen Merge zwischen D und Q und signalisiert somit dem Testteam, dass sie testen können.

      Wenn die Tests abgeschlossen sind, dann kann der Administrator zwischen Q und P einen Merge durchführen. Der P-Branch wird dann entweder exportiert oder der Administrator deployed ihn direkt auf das Kundensystem und der Kunde hat nun eine neue Version der Applikation.

      Rebase

      Wenn wir uns die obenstehende Grafik genauer anschauen, dann werden wir erkennen, dass durch einen Merge immer ein „unnötiger“ Commit entsteht.

      Durch Rebase können wir auch dieses – oft von Entwicklern empfundene – Designproblem lösen und einen sauberen Entwicklungsstrang ohne „Merge-Commits“ aufbauen.

      Nehmen wir an, wir haben lokal einen Feature Branch gemacht. Dort haben wir fleißig entwickelt und möchten jetzt unsere Änderungen wieder auf den Master Branch bekommen:

      Wenn wir jetzt ein Rebase von unserem Feature auf den Master Branch machen, dann schauen unsere Commits wie folgt aus:

      Nichtsdestotrotz müssen wir an dieser Stelle noch einen Merge machen, da passiert aber wiederum nichts anderes, als das der Zeiger von dem alten Commit auf den neuesten Commit bewegt wird, jedoch mit dem Unterschied, dass wir an dieser Stelle keinen zusätzlichen Commit für das Mergen erzeugen:

      Jetzt schaut unser Master Branch sauber aus, wir haben einen sauberen Entwicklungsstrang und ein Außenstehender würde meinen, dass wir keinen Feature Branch – sprich keinen weiteren Branch – für die Entwicklung verwendet haben.

      Rebase mit Konflikten

      Wenn es zu einem Konflikt kommt, so wird das nicht, wie bei einem Merge, in einem extra Commit verpackt, sondern die zwei Commits, die von den Änderungen betroffen sind, werden entweder fusioniert oder einer von den beiden Commits gewinnt. Entscheidungsträger ist hier wiederum der Entwickler, der gerade einen Rebase vornimmt.

       

      Was ist ein Git Reset? 

      Viele „Git-Neulinge“ verwechseln Reset mit Rebase. Oft glaubt man, dass Rebase irgendetwas mit dem Zurücksetzen der Änderungen zu tun hat, was aber nicht stimmt.

      Mit Reset hat man zwei Möglichkeiten um das Zurücksetzen der Daten bzw. den Änderungen bis zu einem, in der Vergangenheit liegenden, bestimmten Commit zu erreichen:

       

      Welche Arten von Git Reset gibt es?

      Hard Reset

      Gehen wir davon aus, dass wir einen Feature Branch eröffnet haben und dem Feature, welches ein Change Request vom Kunden war, eine Absage erteilt wird. Wir wissen schon, dass wir an einem weiteren Feature arbeiten werden, welches aber nichts mit unserem bisherigen Feature Entwicklungen zu tun hat.

      In diesem Fall werden wir einen Hard Reset machen. Die bisherigen Entwicklungen am Feature Branch werden verworfen und der Feature Branch wird mit dem ausgewählten Branch, in unserem Fall dem Master Branch, gemerged um wieder auf dem gleichen Datenstand zu sein:

      Mixed Reset

      Bei einem Mixed Reset schaut das ganze fast gleich aus, mit dem Unterschied, dass wir nicht alles verwerfen, sondern einige Änderungen, die sich in der Staging Area befinden, mitgenommen werden können.

      Zusammenfassung

      Nachdem wir mit dieser Git Anleitung jetzt einiges über Git wissen und auch schon die wichtigsten Begrifflichkeiten und Funktionalitäten kennengelernt haben, können wir uns im dritten Teil unserer Blogreihe ansehen, wie man Git effizient bei der Entwicklung mit der SAP WebIDE einsetzt.