Repos
Diese Hilfe befasst sich mit dem Inhalt des Services Repo.
Files
Unter Files hat man eine Übersicht aller Dateien, die in dem Repo hinterlegt wurden.
Unterschieden wird hier noch zwischen den Branches. Jede Branch hat seine eigene kleine Repo, die logische Struktur ist hier:
Repo -> Branches -> Files
Über die Files ist es auch möglich, das Repo auf eine lokale Maschine zu klonen. Hier gibt es diverse Optionen, dies auszuführen, ganz nach Belieben des Users.
Commits
Begriffserklärung
Über Commits werden Änderungen an Repos übernommen. Wenn mit Visual Studio Code gearbeitet wird, würde man nach seinen Anpassungen ein Commit ausführen, welches dafür sorgt, dass der Commit in die lokale Repo übernommen wird. Beim Pushen in ein remote Repo (Bsp. DevOps) wird auch dann nur die Änderung mitgenommen, wenn diese in einem Commit enthalten ist.
Commits in DevOps
Unter den Commits bekommt man eine Übersicht der in DevOps enthaltenen Commits. Diese sind wieder in die einzelnen Branches unterteilt.
Mit einem Graphen bekommt man eine sehr vereinfachte Übericht des Commit-Verlaufs in dieser Branch. Mit einem Klick auf solch einen Commit bekommt man hier eine gute Übericht über die Änderunge, die in diesem Commit enthalten sind.
Hier wird immer sehr schön hervorgehoben, was sich in diesem Commit alles geändert hat.
Im Falle, dass sich in einem Commit ein Fehler eingeschlichen hat, gibt es die Möglichkeit, Commits zu Reverten. Dies führt dazu, dass DevOps zwar die Änderungen bis zu diesem Commit rückgängig macht, jedoch werden die Commits nicht entfernt, es wird einfach automatisch ein neues Commit erstellt, welches die Änderungen zurücksetzt.
Pushes
Pushes pushen Commits nach DevOps. Hier erhält man ähnliche Informationen wie in den Commits, jedoch werden diese hier in Pushes grupiert, in welchen die Commits übertragen wurden.
Branches
Hier bekommt man eine Übersicht aller Branches, die zu dem Projekt/dem Repo gehören. Möglichkeiten der Übersicht sind oben auswählbar:
Mine - All - Stale
Über den Button New Branch kann auf dem Remote Repo eine neue Branch erstellt werden.
Branches haben ihre eigenen Einstellungen über das Dropdown auf dem Kebab Menu
New Pull Request
New Pull Request erstellt, wie schon der Name verrät, einen neuen Pull Request auf deine Branch. Ein Pull Request bedeutet, dass die Branch, auf welchen der erstellt wird, auf einen andere Branch zurückgeführt wird. Beispiel:
Aus master wird develop erstellt, nach fertiger Entwicklung sollen die Änderungen aus dem develop zurück in den master
Mehr Informationen gibt es unter Pull Request unterhalb.
Branch Policies
Unter dem Branch Policies findet man wichtige Einrichtungsoptionen für die entsprechende Branch. Dort kann eingerichtet werden, ob beliebige Personen einfach so ihre Änderungen in den master pushen dürfen, oder ob bei einem Pull Request der Ersteller selber sein eigenen Pull Request Aproven kann.
Empfehlung: Den master darf niemand direkt anfassen können. Der Aufwand, Pull Requests in den master zu führen, sollte so sicher sein, wie es einem wichtig ist. Branches, aus denen weitere Branches erstellt werden, sollten auch dementsprechend geschützt werden, hier reichts, dass immer ein Dritter zu einem Pull Request als Reviewer eingeladen wird.
Tags
-/-
Pull Request
Erklärung
Pull Request ersetzen/ erweitern den Vorgang des Reviewens. Wenn eine Aufgabe, für welche im Normalfall eine eigene Branch erstellt wurde, erledigt wurde, startet der Entwickler einen Pull Request auf seine Branch. Es soll seine Entwicklung in die Haupt Entwicklungsbranche zurückgeführt werden. Dabei soll ein Review passieren. Über einen Pull Request hat man nun die Möglichkeit, die Änderungen einzusehen, zu Kommentieren und ggf. zu Akzeptieren.
Create a Pull Request
Oben muss ausgewählt werden von welchem Branch in welchen Branch überführt werden soll. Dabei vergibt man einen Titel für den Pull Request, am besten selbsterklärend (am besten mit Aufgabe, Beschreiben etc.). In der Description kann man weitere Informationen zum Pull Request hinterlegen, welche bspw. für Reviewer interessant sein können.
Unter dem Punkt Reviewers ist es möglich, sich einen Reviewer auszusuchen, der dann den Pull Request verarbeiten soll. Der Reviewer sollte dann auch eine Mitteilung bekommen, dass ein Pull Request seine Aufmerksamkeit bedarf.
Mit Work Items könnte man die Aufgabe gleich mit einpflegen, wenn Boards in DevOps genutzt werden.
Erstellt man nun den Pull Request, kann das Reviewen los gehen.
Active Pull Request
Wenn man auf den erstellten Pull Request klickt, kommt man auf die Übersicht des Pull Requests.
Hier kann man Kommentare hinzufügen, die Policies überwachen und noch mehr.
Klickt man hier auf den Reiter files, kommt erst das interessante.
Auf der linken Seite bekommt man eine Übersicht der berührten Objekte in deren Verzeichnissen. Ein + am Objektnamen kennzeichnet ein Objekt, welches durch den Pull Request hinzu kommen würde. Ein durchgestrichener Name bedeutet, dass durch den Pull Request ein Objekt eliminiert wird.
Auf der rechten Seite befinden sich die Inhalte, welche sich durch den Pull Request ändern würden. Rote Zeilen bedeuten, es wurde was enfertn, grüne Zeilen bedeuten, es wurde was hinzugefügt. Hier ist der Code-Review am einfachsten zu vollziehen. Ein Funktionstest muss manuell im System, oder durch ein Unit Test (Test-Codeunit/ Pipeline) ausgeführt werden.
Jeder Zeile kann hier ein Kommentar hinzugefügt werden. Wenn in der Branch-Policy eingerichtet wurde, dass der Pull Request nur dann erfolgen kann, wenn alle Kommentare Resolved sind, ist das Behandeln von Kommentaren essentiell.
Über den Reiter Updates bekommt man eine Übersicht aller Änderungen, die während des Pull Requests gelaufen sind.
Commits zeigt die Commits auf, die in dem Pull Request enthalten sind.
Hilfreiche Links:
Microsoft Hilfe
