SE-Tutorium 4 | Mittwoch 16 - 18 Uhr:

anchored to [[191.00_anchor]]


Lernziele:

  1. Probleme mit Branching beseitigen
  2. Merging branches, konzeptuelles Verständnis beim mergen
  3. Merge conflicts ( speedrun) –> wir möchten uns kurz einen anschauen und lösen
  4. wie funktionieren remotes “origin/???”
  5. Issues schreiben, Key Punkte dieser wissen
  6. Pull Requests erstellen können
  7. Pull Requests Reviewen
    1. wissen, was ein Review ausmacht
    2. Qualität von Reviews
    3. selbst Reviews schreiben können oder zumindest probieren!
  8. mit einer IDE arbeiten
  9. Github Flow probieren

Im Tutorium Ankommen:

note: dunno, erzählen, was ich gerade mache?


| Inhalte des Tutoriums:

  1. HW 2 / HW 3
  2. kurz branching anschauen –> Probleme, Backups erstellen!
  3. Merging kurz anschauen –> was passiert bei Git?
  4. deskriptive (gute) Issues erstellen und verlinken!
  5. Pull Requests / Reviews verstehen und umsetzen können
    1. Beispiele für Pull Requests / Reviews finden!
  6. mit einer IDE arbeiten! –> besseres Coding!
  7. Github Flow -> entsprechend im Team arbeiten und koordinieren.

note: ~2 min


HW 2 / HW 3

  • Fragen zu den Aufgaben?

note: dont take longer than roughly 5 minutes


Branches | Commits im Verlauf markieren:

  • Branches nützlich, um getrennt an Dingen zu arbeiten
    • oder Features unabhängig entwickeln zu können
    • (gleichzeitig) neue Website, neue Documentation, neue Firmware schreiben
  • Branches sind nichts weiter als “Zeiger” auf Commits
    • daher können wir sie beliebig irgendwo setzen!
  • -> bei Git werden sie netterweise automatisch weitergerückt, wenn ein neuer Commit hinzukommt

letzte Woche im Tutorium!<-> Fragen gerne stellen!

note: around 3 - 4 min max!


| Branch “Backup” erstellen

  • Veränderungen eines Branches manchmal schwer zurückzusetzen

    • etwa falsch rebased –> wie den Originalzustand herstellen?
  • mögliches Vorgehen?

  1. Checkout zum feature-branch, etwa “featureX” git checkout featureX
  2. Erstelle neuen Branch, etwa “featureX/backup” git branch featureX/backup
  3. Änderungen in “featureX” anwenden
    1. Fehler vorgefallen, aber schon comitted, ( aber noch nicht pushed! ) :(
    2. zurück zum backup-branch switchen git checkout featureX/backup
  4. branch zu Backup-Stand zurücksetzen git reset --hard my-feature-backup

note: 4 min


| Merging - Branches zusammenführen:

  • wird in HW1 aktiv geübt und angewandt!
  • mit Merging können wir Branches wieder zusammenführen
    • also Änderungen zusammenführen
  • hier wird wichtig. wie git commits darstellt!
    • parent(s), auf die ein Commit aufbaut!

note: draw commit line that has branch and wants to merge it again. smth like ->commit->commit|->main-1->main … Ask on how it would be merged again then! –> what does git do now? more infos here


| Merge Conflicts -> what?

  • Merge conflicts treten auf –> zwei (oder mehr!) Commits (werden gemerged):
    • verändern Datei an gleicher Stelle –> welche nehmen wir jetzt?
    • müssen gelöst werden, sonst könnten Informationen verloren gehen
  • git setzt flags in die Datei!
    • -> vereinfachen Verständnis der Änderungen
    • –> geben an was, wo verändert wurde!
<<<<<<< HEAD
<p>Hey so you may remembered that merge conflicts sometimes appear when editing the same line in two different commits and then merge them together, right?</p>
=======
<p> its like I'm from another dimension, I can predict that this will cause issues?</p>
>>>>>>> feature/javascriptGame

note: 4 - 5 min


| Rebasing - Commits aufspielen

  • funktionieren anders, als merges
  • Änderungen werden nicht von =vielen Commits zusammengeführt
  • sondern –> Änderung Branches auf die Commits eines Anderen aufgelegt
  • aus den Docs von git.
Assume the following history exists and the current branch is "topic":

                     A---B---C topic
                    /
               D---E---F---G master

       From this point, the result of either of the following commands:

           git rebase master
           git rebase master topic

       would be:

                             A'--B'--C' topic
                            /
               D---E---F---G master

note: 4 - 5 min


| Rebasing - rückgängig machen:

  • bei einem rebase wird der Startpunkt im ORIG_HEAD gespeichert
    • bei Fehlern –> zu diesem Zurücksetzen
    • !Achtung: funktioniert nur, wenn danach noch nichts gemacht wurde
  • wenn danach Änderungen vorgenommen wurden, können wir den Branch nehmen und zurücksetzen!
  • dafür git reset --hard featureBranch@{1} -> wird den Stand auf den des Branches vor einem Schritt zurücksetzen
  • further reading
  • src

note: Beispiel -> FeatureA auf main –> wieder zurücksetzen mit git reset --hard feature@{1}


Remotes | Git-Repo aber woanders ?

  • Remotes prinzipiell einfach Möglichkeit git nicht lokal zu nutzen
  • Github, Gitlab, sourcehut … als mögliche remotes
    • –> Änderungen des Repos hochladen und teilen können
    • <– Repo herunterladen und bearbeiten können

=> Teamarbeit!

note: maybe around 2 - 3 minutes


Remotes | Git-Repo in der Cloud??:

  • wir nutzen primär Github (HW0, HW1, HW2, HW3 …)

  • (Vorhandenes Repo lokal nutzen!):

    • Herunterladen eines Repos: git clone git@linkToGithubRepository.git (wichtig, .git am Ende –> SSH_Authentication!)
    • updates ziehen! git pull -all
    • was geht ab ?? git log --oneline --graph --decorate --all
  • vielleicht auch Repo lokal erstellen und dann auf Github erstellen?: Schritte dafür:

  1. git init repo … add commits etc
  2. git remote add origin git@githubLinkToRepo.git ( Link aus “Code”-Button kopieren )
  3. git fetch --all download changes from repo ?
  4. git push hochladen der Changes

note: not more than 5 minutes


Issues | Probleme, Anmerkungen für Projekte

  • Issues –> Tool, um Fehler, Probleme, Bugs, Feature-Request und mehr zu dokumentieren und beschreiben
    • “aah deine Website crashed wenn man …. eingibt”
    • “es wäre cool, wenn man noch das und das einfügen könnte”
  • Also Infos/ Probleme bezüglich eines Projektes –> beschreiben.
    • Diskussion aufbauen
  • (auf Github) können wir sie später referenzieren!
  • Inhalt ist wichtig!
    • –> was passiert
    • –> wie passiert es
    • –> “steps to reproduce”
  • Label
    • (github) können helfen entsprechend zu kategorisieren

note: rough 5 min will lead to teamwork task afterwards!


sinnvoll / gut Issues schreiben:

wie sehen gute Issues aus?

  1. Findet ein großes / größeres Repository auf Github ( egal welches Projekt)
  2. Issues von diesem Repository anschauen
  3. wie nutzen sie die Tags? Was für welche?
  4. wie sind die Issues beschrieben -> ausführlich, weniger?
  5. folgen die Issues einem Schema?
  6. findet ein Issue, das gut ist –> Warum?

note: this should tkae around 10 minutes! good : https://github.com/codeforamerica/brigade/issues/344 badish : https://github.com/nicolasseng/teamproject-objectdetection/issues/22 ? –> ask them whether it is good or not?


Pull Requests & Reviews | Änderungen einbringen

  • Pull Requests immer dann, wenn von einem Branch auf einen anderen merge passieren soll
    • (kann man auch ohne PR machen, aber bei großen Repositories mit vielen Menschen wird das nix :D )
  • geben Übersicht –> Was wurde, von wem, wie, weswegen geändert
    • –> löst Issue
    • –> neues Feature?
    • –> was wurde verändert?
  • (da Branch) –> zeigt alle Commits, die in diesem getätigt wurden.
  • Issues können gelinkt werden!

note: 5 -6 min ask –> PRs können von allen Personen erstellt werden. Bei großer Codebase, wann würde man etwa unterschiedliche Autor*innen für PR und Issue haben (beide referenzieren sich?).


Pull Request (PR) -> Erstellen:

  • Erstellen ist relativ einfach
  • benötigt Source und Target Branch

![[Pasted image 20231108010206.png]]

  • Anschließend unter Reiter “Pull Request” –> “New Pull Request” klicken
    • Beschreibung einfügen !
  • können hier die Änderungen des Branches einsehen!
    • listet auch Commits!
  • BSP: keyboard repo

Pull Request –> Reviewen:

  • Änderungen müssen von Mistreitenden auch abgenommen/akzeptiert werden
    • “ist die Änderung sinnvoll?”
    • “läuft sie bei mir (lokal??)”
    • “werden aus Versehen neue Fehler eingebracht”?
  • Reviewers –> Zugeschrieben Personen, die den Code anschauen und beurteilen sollen!
    • “ passt / passt nicht“ –> “änder das oder das nochmal!” …
  • Review erstellen –> Änderungen aktiv kommentieren,
    • Feedback geben
    • Verbesserungen vorschlagen!
    • Änderungen zustimmen

![[Pasted image 20231108010518.png]]

note: rough 5 min guide to discussion afterwards! –> whats good reviewing? same reference -> my repo https://github.com/ScatteredDrifter/Quasar-67/pull/8


Reviews, aber gut:

  • Reviews sind wichtig
    • Feedback
    • Verbesserungen
  • daher müssen sie sinnig formuliert sein!

Aufgabe:

findet heraus, wie man gute Code Reviews schreiben kann

  • Verhalten?
  • Perspektive des Schreibens?
  • Kontext vermitteln?
  • müssen wir schon eine konkrete Lösung vorgeben / finden? Quellen dafür: “The Standard of Code Review” (google.github) -> https://google.github.io/eng-practices/review/reviewer/comments.html#summary -> https://google.github.io/eng-practices/review/reviewer/standard.html

note: give them 5 - 10 minutes


Social Coding | Probieren

  • Wir wollen mit einer großen Menge von Teilnehmenden arbeiten mit Repositories üben
  • Repository für Tutorium vorbereitet
    • wir wollen die Codebase verstehen, betrachten und anpassen!

IDE | Verstehen, Features nutzen

  • IDE - Integrated Development Environment
  • average texteditor aber mit vielen vielen Features
    • highlighting
    • Vorschläge
    • Go-To
    • refactoring
    • debugging, static checks
  • in unserem Repository anschauen ( und anschließend selbst probieren!)

note: 3 - 5 min demo intellij / vscode -> type declaration, function explanation, etc getting to know codebase


Social Coding | Probieren

  • dafür folgende Aufgabe:
  1. Clone this repository: se-tuebingen-exercises-ws23/ex3-tutN where N is the number of your tutorial
  2. Open it in the IntelliJ IDE.
  3. Run the project.
  • In IntelliJ: use the green run button ▶️ on the top right
    • If it doesn’t work straight away, try adding a new configuration -> sbt task -> run, see the IntelliJ guide on the forum.
    • If you prefer the command line: use the command sbt run.
  • If you have any problems with your setup, please, ask on the forum.
  1. get to know codebase
    • öffne unser heruntergeladenes Repository mit deiner IDE ( Intellij, Vscode …)

    • was für enums und Klassen gibt es?
    • wo wird der Nutzer*innen Input eingefügt?
    • wie sind die diversen Features implementiert? ( wo? )
  2. On the main branch, add your GitHub username to the list of students in peopleNames, while keeping the list sorted.
  3. Run the project again to test that everything works.
  4. Commit your changes to the main branch and push your changes.

note: 10 - 15 min sollte helfen und sie sollten die Probleme darin finden


GitHub Flow - Solving overlapping work

  1. warum kann nicht jede Person auf “main” committen
  2. Lösung dazu??
  3. wie könnten wir die Implementation von “FeatureX” nun umsetzen / planen?
    1. Issue erstellen ( beschreiben, was implementiert werden soll)
    2. Branch “feature/FeatureX” erstellen, um dann die Arbeit darin zu vollbringen
    3. Pull-Request, nachdem das Feature implementiert wurde
    4. Review PR, um Fehler, Verbesserungen, Anmerkungen vorzunehmen ( bevor man sie in den Hauptcode packt!)
  4. Links ( https://docs.github.com/en/get-started/quickstart/github-flow oder “github flow” suchen)

note: Please make this a discussion! helps to integrate everyone! FeatureX -> described by one person, added and implemented by another, reviewed by yet another person ?


GitHub Flow - Probieren im Repo

Aufgabe:

  • Try GitHub Flow out on this repository!
  • Your goal is to add something new to this project
    • example: new responses, new rooms, some new functionality, …
  • Use GitHub Flow: make an issue, then a pull request, assign a reviewer, then merge.
  • Notes: You might need to reset your local changes! (And possibly even reset some commits…)

note: this chould occupy the most time as it helps to fundamentally work with github flow, java and an ide!


Feedback

  • Welche Süßigkeiten präferiert ihr?
  • sollten sie Vegan sein?
  • gibt es noch Fragen für diese Stunde?
    • Fragen zu Korrekturen?
    • Fragen zu Inhalten oder Orga?
  • gerne auch persönlich / Im Forum fragen!
  • Hw2 und Hw3 gerade aktiv!

Resources:

  • writing good commits or code reviews:
    • https://www.freecodecamp.org/news/git-best-practices-commits-and-code-reviews/
    • https://github.com/codeforamerica/howto/blob/master/Good-GitHub-Issues.md
  • mein geteiltes Repo!
  • some more later, sorry //