SE-Tutorium 4 | Mittwoch 16 - 18 Uhr:
anchored to [[191.00_anchor]]
Lernziele:
- Probleme mit Branching beseitigen
- Merging branches, konzeptuelles Verständnis beim mergen
- Merge conflicts ( speedrun) –> wir möchten uns kurz einen anschauen und lösen
- wie funktionieren remotes “origin/???”
- Issues schreiben, Key Punkte dieser wissen
- Pull Requests erstellen können
- Pull Requests Reviewen
- wissen, was ein Review ausmacht
- Qualität von Reviews
- selbst Reviews schreiben können oder zumindest probieren!
- mit einer IDE arbeiten
- Github Flow probieren
Im Tutorium Ankommen:
note: dunno, erzählen, was ich gerade mache?
| Inhalte des Tutoriums:
- HW 2 / HW 3
- kurz branching anschauen –> Probleme, Backups erstellen!
- Merging kurz anschauen –> was passiert bei Git?
- deskriptive (gute) Issues erstellen und verlinken!
- Pull Requests / Reviews verstehen und umsetzen können
- Beispiele für Pull Requests / Reviews finden!
- mit einer IDE arbeiten! –> besseres Coding!
- 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?
- Checkout zum feature-branch, etwa “featureX”
git checkout featureX
- Erstelle neuen Branch, etwa “featureX/backup”
git branch featureX/backup
- Änderungen in “featureX” anwenden
- Fehler vorgefallen, aber schon comitted, ( aber noch nicht pushed! ) :(
- zurück zum backup-branch switchen
git checkout featureX/backup
- 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
- Herunterladen eines Repos:
-
vielleicht auch Repo lokal erstellen und dann auf Github erstellen?: Schritte dafür:
git init repo
… add commits etcgit remote add origin git@githubLinkToRepo.git
( Link aus “Code”-Button kopieren )git fetch --all
download changes from repo ?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?
- Findet ein großes / größeres Repository auf Github ( egal welches Projekt)
- Issues von diesem Repository anschauen
- wie nutzen sie die Tags? Was für welche?
- wie sind die Issues beschrieben -> ausführlich, weniger?
- folgen die Issues einem Schema?
- 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!
- –> somit nachvollziehbar, warum PR erstellt wurde!
- example of my teamproject
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:
- Clone this repository:
se-tuebingen-exercises-ws23/ex3-tutN
whereN
is the number of your tutorial- Open it in the IntelliJ IDE.
- 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.
- 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? )
- On the
main
branch, add your GitHub username to the list of students inpeopleNames
, while keeping the list sorted.- Run the project again to test that everything works.
- 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
- warum kann nicht jede Person auf “main” committen
- Lösung dazu??
- wie könnten wir die Implementation von “FeatureX” nun umsetzen / planen?
- Issue erstellen ( beschreiben, was implementiert werden soll)
- Branch “feature/FeatureX” erstellen, um dann die Arbeit darin zu vollbringen
- Pull-Request, nachdem das Feature implementiert wurde
- Review PR, um Fehler, Verbesserungen, Anmerkungen vorzunehmen ( bevor man sie in den Hauptcode packt!)
- 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 //