Quick recap

In meinem letzten Blogbeitrag zum Thema Git in der SAP Web IDE habt ihr den Unterschied zwischen zentraler und dezentraler Versionskontrolle kennengelernt und dabei folgendes über Git erfahren:

• Bei Git handelt es sich um eine dezentrale Versionskontrolle
• Ein Commit ist als neue Version eines Repositories zu verstehen
• Ein Branch ist ein Zeiger auf einen Commit und somit auf eine bestimmte Version

Git in der SAP Web IDE – Let’s get ready to rumble!

Nachdem ich euch viel zu lange mit theoretischem Wissen gelangweilt habe ist nun der Zeitpunkt gekommen sich die Hände schmutzig zu machen und die grundlegenden Funktionen eines Git-Repositories kennen zulernen.

Saving –> Staging –> Committing

Änderungen im Code eines Projektes innerhalb der SAP Web IDE müssen selbstverständlich gespeichert werden. Entweder manuell, oder indem man Autosave unter
Preferences->Code Editor aktiviert.

Sobald eine Datei über gespeicherte Änderungen verfügt, kann man sie via Stage File Git zur Verfügung stellen. Die Gesamtheit der Dateien, die Git via Staging zur Verfügung gestellt werden nennt man einen Snapshot. Snapshots kann man sich als potenzielle, zukünftige Commits vorstellen.
Wenn ihr alle notwendigen Änderungen an eurem Projekt durchgeführt, gespeichert und via Stage File zu einem Teil des aktuellen Snapshots gemacht habt ist es an der Zeit für den Commit.
Durch den Commit-Befehl weist ihr Git dazu an, den aktuellen Snapshot zu einer neuen Version des ausgewählten Repositories zu machen.

Stashing

Der Stash eines GitRepositories adressiert ein gelegentlich auftretendes Problem, dass man am besten versteht, wenn es einem an einem Beispiel aus der Praxis erläutert wird:
Stellt euch vor ihr seid mitten in der Entwicklung eines neuen Features, wenn euch ein Ticket für einen sehr dringenden Bugfix erreicht. Ihr wollt euren Code und somit die Arbeit an dem neuen Feature selbstverständlich nicht einfach löschen, möchtet aber genauso ungerne eine neue Version erstellen, da das Feature noch längst nicht funktionstüchtig ist. In diesem Szenario ist der Stash die optimale Lösung, da er eine Möglichkeit bietet (lokal oder anderweitig) zu speichern ohne den aktuellen Stand des Repositories zu verändern. Das bedeutet, dass Git alle gespeicherten Änderungen, unabhängig davon ob sie innerhalb der Staging Area ausgewählt wurden oder nicht, in den Stash speichert und gleichzeitig den Code in deinem Web IDE Workspace auf den Stand des letzten Commits zurücksetzt. Ihr könntet den Bug nun entspannt bearbeiten, die neue stabile Version zu einem neuen Commit machen und sie selbstverständlich deployen. Anschließend holt ihr einfach via Apply Stash den Code eures Features aus eurem “virtuellen Versteck” hervor und könnt  die Arbeit an ihm fortsetzen.

Reverting

Reverting in der SAP Web IDE via Git ist einfach, aber nichtsdestotrotz sehr mächtig. Jeder Commit kann via Revert rückgängig gemacht werden. Git erstellt bei jedem Revert einen neuen Commit, in dem der rückgängig gemachte Code enthalten ist. Das bedeutet, dass man nicht nur den letzten Commit rückgängig machen kann, sondern jeden beliebigen. Ihr seid also dazu in der Lage fehlerhafte oder ungeliebte Änderungen aus der Vergangenheit einfach rückgängig zu machen, ohne die darauf folgenden neueren Commits zu verlieren. Vorausgesetzt ihr habt euch an die Konvention gehalten, jedem neuen Feature ein eigenen Commit zu spendieren ;-).
Das war’s für Heute! Im dritten Teil dieser Serie widmen wir uns Push und Merge.

Ich hoffe Ihr schaut dann wieder rein. Bis bald!

Du interessierst dich für Fiori und hast Lust coole Projekte mit uns zu machen? Wir suchen dich! Schau doch mal in unserer Stellenbeschreibung vorbei.