Deploying to gh-pages from @ 1301c47 🚀

einfuehrung.html

@@ -188,7 +188,7 @@ <h2 id="workshop-ziele"><a class="header" href="#workshop-ziele">Workshop-Ziele<
 darin enthaltenen Abstraktionsmechanismen qualitativ hochwertigen Code zu schreiben. SOLID ist ein Akronym für fünf Designprinzipien, die die Erstellung von Software erleichtern und die Wartbarkeit und Erweiterbarkeit des Codes verbessern.</p>
 </li>
 <li>
-<p><strong>Code-Smells</strong>: Lerne gängige "Code Smells" zu erkennen und zu beheben. "Code Smells" sind Anzeichen im Quellcode, die möglicherweise tiefer liegende Probleme signalisieren. Identifiziert und überarbeite schlechten Code, um die Qualität und Lesbarkeit eures Projekts zu verbessern.</p>
+<p><strong>Code-Smells</strong>: Lerne gängige &quot;Code Smells&quot; zu erkennen und zu beheben. &quot;Code Smells&quot; sind Anzeichen im Quellcode, die möglicherweise tiefer liegende Probleme signalisieren. Identifiziert und überarbeite schlechten Code, um die Qualität und Lesbarkeit eures Projekts zu verbessern.</p>
 </li>
 <li>
 <p><strong>SCRUM</strong>: Lerne die grundlagen von Agilem Projektmanagement und Scrum. Die Methodik ist weitverbreitet und unterstützt Teams dabei, in iterativen Sprints effizeint und produktiv zu arbeiten.</p>

git/branching_und_merging.html

@@ -190,7 +190,7 @@ <h1 id="branching"><a class="header" href="#branching">Branching</a></h1>
 <blockquote>
 <p>Die <code>-b</code> Flag steht hierbei für <code>branch</code>.</p>
 </blockquote>
-<p>In git gilt der Grundsatz: "Branch early, branch often". Das heißt du wirst in der Regel mit vielen Branches konfrontiert sein. Diese alle über das Log zu verfolgen ist nicht immer sinnvoll. Solltest du einfach nur wissen wollen, welche Branches es gibt, kannst du das mit dem Befehl <code>git branch</code> tun.</p>
+<p>In git gilt der Grundsatz: &quot;Branch early, branch often&quot;. Das heißt du wirst in der Regel mit vielen Branches konfrontiert sein. Diese alle über das Log zu verfolgen ist nicht immer sinnvoll. Solltest du einfach nur wissen wollen, welche Branches es gibt, kannst du das mit dem Befehl <code>git branch</code> tun.</p>
 <pre><code class="language-bash">$ git branch
 &gt; * feature/1
   main
@@ -286,7 +286,7 @@ <h1 id="merge-conflicts"><a class="header" href="#merge-conflicts">Merge Conflic
 $ cat foo.txt
 &gt; Hello Bob!
 </code></pre>
-<p>Wenn wir jetzt <code>feature/1</code> in <code>main</code> mergen wollen, wird es zwangsweise zu einem Merge-Konflikt kommen, da nicht klar ist ob es "Hello Alice" oder "Hello Bob" heißen soll.</p>
+<p>Wenn wir jetzt <code>feature/1</code> in <code>main</code> mergen wollen, wird es zwangsweise zu einem Merge-Konflikt kommen, da nicht klar ist ob es &quot;Hello Alice&quot; oder &quot;Hello Bob&quot; heißen soll.</p>
 <pre><code class="language-bash">$ git checkout main
 $ git merge feature/1
 &gt; Auto-merging foo.txt
@@ -297,14 +297,14 @@ <h1 id="merge-conflicts"><a class="header" href="#merge-conflicts">Merge Conflic
 <pre><code class="language-bash">$ git status
 &gt; On branch main
   You have unmerged paths.
-    (fix conflicts and run "git commit")
-    (use "git merge --abort" to abort the merge)
+    (fix conflicts and run &quot;git commit&quot;)
+    (use &quot;git merge --abort&quot; to abort the merge)
 
   Unmerged paths:
-    (use "git add &lt;file&gt;..." to mark resolution)
+    (use &quot;git add &lt;file&gt;...&quot; to mark resolution)
 	  both modified:   foo.txt
 
-  no changes added to commit (use "git add" and/or "git commit -a")
+  no changes added to commit (use &quot;git add&quot; and/or &quot;git commit -a&quot;)
 
 </code></pre>
 <p>Schauen wir uns mal an wie so ein Merge-Konflikt in der Datei aussieht:</p>
@@ -321,7 +321,7 @@ <h1 id="merge-conflicts"><a class="header" href="#merge-conflicts">Merge Conflic
 </code></pre>
 <p>Um git mitzuteilen, dass wir den Konflikt zu unserer Zufriedenheit gelöst haben, müssen wir die Datei <code>foo.txt</code> mit <code>git add</code> der Staging Area hinzufügen und dann einen ganz normalen Commit erstellen.</p>
 <pre><code class="language-bash">$ git add foo.txt
-$ git commit -m "Merge feature/1 into main"
+$ git commit -m &quot;Merge feature/1 into main&quot;
 </code></pre>
 <blockquote>
 <p>Solltet ihr während des Merge-Prozesses feststellen, dass ihr einen Fehler gemacht habt oder noch nicht bereit für den Merge seit, könnt ihr jederzeit den Merge mit <code>git merge --abort</code> abbrechen. Damit werden alle Änderungen zurückgestzt als ob der Merge nie angefangen wurde.</p>

git/changing_history.html

@@ -214,7 +214,7 @@ <h3 id="bearbeiten-von-älteren-commits"><a class="header" href="#bearbeiten-von
 # r, reword &lt;commit&gt; = use commit, but edit the commit message
 # e, edit &lt;commit&gt; = use commit, but stop for amending
 # s, squash &lt;commit&gt; = use commit, but meld into previous commit
-# f, fixup &lt;commit&gt; = like "squash", but discard this commit's log message
+# f, fixup &lt;commit&gt; = like &quot;squash&quot;, but discard this commit's log message
 # x, exec &lt;command&gt; = run command (the rest of the line) using shell
 # b, break = stop here (continue rebase later with 'git rebase --continue')
 # d, drop &lt;commit&gt; = remove commit

git/checkout_und_reset.html

@@ -324,13 +324,13 @@ <h1 id="checkout"><a class="header" href="#checkout">Checkout</a></h1>
   commit id: &quot;656d54&quot; type: HIGHLIGHT
   commit id: &quot;de5234&quot;
 </pre>
-<p>An sich kein Problem. Der HEAD zeigt jetzt auf den Commit <code>656d54</code> und unser Working Tree ist auf dem passenden Stand gebracht. Aber warum werden wir darauf hingeweisen dass wir jetzt in einem "detached HEAD" Zustand sind? Und was ist das überhaupt?</p>
-<p>Braches zeigen immer auf den letzten Commit ihres Zweiges. Und Branches sind die einzigen Orte an denen wir neue (erreichbare) Commits erstellen können. "detached HEAD" beschreibt also den Zustand indem wir nicht mehr direkt auf einen Branch verweisen und somit auch keinen neuen Commit erstellen sollten.</p>
+<p>An sich kein Problem. Der HEAD zeigt jetzt auf den Commit <code>656d54</code> und unser Working Tree ist auf dem passenden Stand gebracht. Aber warum werden wir darauf hingeweisen dass wir jetzt in einem &quot;detached HEAD&quot; Zustand sind? Und was ist das überhaupt?</p>
+<p>Braches zeigen immer auf den letzten Commit ihres Zweiges. Und Branches sind die einzigen Orte an denen wir neue (erreichbare) Commits erstellen können. &quot;detached HEAD&quot; beschreibt also den Zustand indem wir nicht mehr direkt auf einen Branch verweisen und somit auch keinen neuen Commit erstellen sollten.</p>
 <blockquote>
-<p>‼️ Achtung: Commits sind nur über Branches erreichbar. Im "detached HEAD" können wir zwar Commits erstellen, aber sie sind nicht erreichbar. Um sie dauerhaft erreichen zu können müssen wir sie einen neuen Branch erstellen (<code>git branch &lt;branch_name&gt;</code>). Solltet ihr das vergessen wird euch git beim nächsten Checkout auf einen Branch darauf hinweisen. Falls ihr das vergesst ist es Zeit die Seite <a href="./help.html">Help! I fucked up</a> zu lesen.</p>
+<p>‼️ Achtung: Commits sind nur über Branches erreichbar. Im &quot;detached HEAD&quot; können wir zwar Commits erstellen, aber sie sind nicht erreichbar. Um sie dauerhaft erreichen zu können müssen wir sie einen neuen Branch erstellen (<code>git branch &lt;branch_name&gt;</code>). Solltet ihr das vergessen wird euch git beim nächsten Checkout auf einen Branch darauf hinweisen. Falls ihr das vergesst ist es Zeit die Seite <a href="./help.html">Help! I fucked up</a> zu lesen.</p>
 </blockquote>
 <blockquote>
-<p>Solltet ihr noch einen ältere Version von git haben, ist der Hinweis noch deutlich dramatischer und warnt deutlich agressiver, dass Commits verloren gehen können. "detached HEAD" ist aber ein normaler Zustand und kein Grund zur Panik. Wenn ihr ihn wieder verlassen wollt, könnt ihr einfach auf einen Branch wechseln. Zum Beispiel mit <code>git checkout main</code>.</p>
+<p>Solltet ihr noch einen ältere Version von git haben, ist der Hinweis noch deutlich dramatischer und warnt deutlich agressiver, dass Commits verloren gehen können. &quot;detached HEAD&quot; ist aber ein normaler Zustand und kein Grund zur Panik. Wenn ihr ihn wieder verlassen wollt, könnt ihr einfach auf einen Branch wechseln. Zum Beispiel mit <code>git checkout main</code>.</p>
 </blockquote>
 <h3 id="relative-commits"><a class="header" href="#relative-commits">Relative Commits</a></h3>
 <p>Navigation mit Commit Hashes ist nicht immer das angenehmste. Warum sollte man eine komische Buchstaben und Zahlenkombination erst im Log raussuchen und dann eingeben um einfach einen Commit zurück zu gehen. Hier kommen Relative Pfade ins Spiel.</p>
@@ -575,7 +575,7 @@ <h1 id="squashing"><a class="header" href="#squashing">Squashing</a></h1>
     Working --&gt; v3
 </pre>
 <p>In der Staging Area und im Working Tree befinden sich nun die Änderungen aller Commits die wir zusammenfassen wollen. Jetzt müssen wir nur noch einen neuen Commit erstellen.</p>
-<pre><code class="language-bash">$ git commit -m "Squashed commit"
+<pre><code class="language-bash">$ git commit -m &quot;Squashed commit&quot;
 </code></pre>
 <pre class="mermaid">gitGraph
 
@@ -592,22 +592,22 @@ <h1 id="stashing"><a class="header" href="#stashing">Stashing</a></h1>
 <p>Beispiel:</p>
 <pre><code class="language-bash">$ git status
 &gt; Changes to be committed:
-    (use "git reset HEAD &lt;file&gt;..." to unstage)
+    (use &quot;git reset HEAD &lt;file&gt;...&quot; to unstage)
 
 	  modified:   bar.txt
 
   Changes not staged for commit:
-    (use "git add &lt;file&gt;..." to update what will be committed)
-    (use "git checkout -- &lt;file&gt;..." to discard changes in working directory)
+    (use &quot;git add &lt;file&gt;...&quot; to update what will be committed)
+    (use &quot;git checkout -- &lt;file&gt;...&quot; to discard changes in working directory)
 
 	  modified:   src/foo.txt
 </code></pre>
 <p>Wir wollen jetzt Branch wechseln, aber die Änderungen in <code>src/foo.txt</code> sind noch nicht commit-bereit. Mit <code>git-stash</code> können wir die Änderungen temporär speichern.</p>
 <pre><code class="language-bash">$ git stash
 &gt; Saved working directory and index state \
-   "WIP on master: 049d078 Create index file"
+   &quot;WIP on master: 049d078 Create index file&quot;
   HEAD is now at 049d078 Create index file
-  (To restore them type "git stash apply")
+  (To restore them type &quot;git stash apply&quot;)
 </code></pre>
 <p>Working Tree und Staging Area sind jetzt wieder auf dem Stand vom letzten Commit und damit bereit den Branch zu wechseln. Wir können das mit <code>git status</code> überprüfen.</p>
 <pre><code class="language-bash">$ git status
@@ -620,19 +620,19 @@ <h1 id="stashing"><a class="header" href="#stashing">Stashing</a></h1>
 &gt; stash@{0}: WIP on master: 049d078 Create index file
 &gt; stash@{1}: WIP on master: 3923d03 Revert add file size
 </code></pre>
-<p>Hier sehen wir das wir zwei Stashes haben. Den oberen haben wir grade erstellt. Um die Stashes unterscheiden zu können fügt git immer die Commit Message des letzten Commits hinzu. Wahlweise kann sie auch bei der Erstellung mit der Option <code>-m</code> angegeben werden (z.B. <code>git stash -m "Meine Nachricht"</code>).
+<p>Hier sehen wir das wir zwei Stashes haben. Den oberen haben wir grade erstellt. Um die Stashes unterscheiden zu können fügt git immer die Commit Message des letzten Commits hinzu. Wahlweise kann sie auch bei der Erstellung mit der Option <code>-m</code> angegeben werden (z.B. <code>git stash -m &quot;Meine Nachricht&quot;</code>).
 Um einen Stash kann auf einer beliebigen Branch wiederhergestellt werden, jedoch kann es bei der Anwendung zu Konfliken kommen. Wie diese gelöst werden schauen wir uns im Kapitel <a href="./git/branching_und_merging.html">Branching und Merging</a> an.</p>
 <p>Um unseren Stash auf den aktuellen Working Tree und Staging Area anzuwenden verwenden wir <code>git stash apply</code>. Sollten wir nicht den letzten Stash anwenden wollen müssen wir die ID mit <code>git stash apply stash@{1}</code> angeben.</p>
 <pre><code class="language-bash">$ git stash apply stash@{0}
 &gt; On branch master
   Changes not staged for commit:
-    (use "git add &lt;file&gt;..." to update what will be committed)
-    (use "git checkout -- &lt;file&gt;..." to discard changes in working directory)
+    (use &quot;git add &lt;file&gt;...&quot; to update what will be committed)
+    (use &quot;git checkout -- &lt;file&gt;...&quot; to discard changes in working directory)
 
 	  modified:   bar.txt
 	  modified:   src/foo.txt
 
-  no changes added to commit (use "git add" and/or "git commit -a")
+  no changes added to commit (use &quot;git add&quot; and/or &quot;git commit -a&quot;)
 </code></pre>
 <p>Wenn wir den Stash nicht mehr benötigen können wir ihn mit <code>git stash drop stash@{0}</code> löschen. Für alle Stashes funktioniert das mit <code>git stash clear</code>.</p>
 

git/datenmodel.html

@@ -176,16 +176,16 @@ <h1 class="menu-title">Software Engineering / Teamprojekt Reference</h1>
                         <h1 id="datenmodel"><a class="header" href="#datenmodel">Datenmodel</a></h1>
 <p>Es gibt viele verschieden Ansätze für die ein VCS zu implementieren. Git verwendet ein sehr einfaches aber durchdachtes Modell, dass uns ermöglicht Features wie Branches, Kollaboration und eine Dateihistorie zu nutzten</p>
 <h1 id="snapshots--commits"><a class="header" href="#snapshots--commits">Snapshots / Commits</a></h1>
-<p>Unser Modell beinhaltet einer Sammlung von Ordnern und Datein in einem "top-level" Ordner - ein Snapshot auch <strong>Commit</strong> genannt. Von git wird eine Datei auch als <code>blob</code> bezeichnet und ist letzendlich nur eine Sammlung aus Bytes. Das Dateiformat spielt somit keine Rolle. Ein Ordner wird als <code>tree</code> bezeichnet und ordnet einem Namen einen oder mehrere <code>blob</code>s und andere <code>tree</code>s zu. Ordner können dementsprechend andere Ordner oder Datein enthalten und sind identisch vom Aufbau zu unserem Dateisystem. Zum Beispiel:</p>
+<p>Unser Modell beinhaltet einer Sammlung von Ordnern und Datein in einem &quot;top-level&quot; Ordner - ein Snapshot auch <strong>Commit</strong> genannt. Von git wird eine Datei auch als <code>blob</code> bezeichnet und ist letzendlich nur eine Sammlung aus Bytes. Das Dateiformat spielt somit keine Rolle. Ein Ordner wird als <code>tree</code> bezeichnet und ordnet einem Namen einen oder mehrere <code>blob</code>s und andere <code>tree</code>s zu. Ordner können dementsprechend andere Ordner oder Datein enthalten und sind identisch vom Aufbau zu unserem Dateisystem. Zum Beispiel:</p>
 <pre><code>&lt;root&gt; (tree)
 |
 +- beispiel (tree)
 |  |
-|  + hello.txt (blob, contents = "hello world")
+|  + hello.txt (blob, contents = &quot;hello world&quot;)
 |
-+- inhalt.txt (blob, contents = "git ist super")
++- inhalt.txt (blob, contents = &quot;git ist super&quot;)
 </code></pre>
-<p>Der top-level <code>tree</code> referenziert den <code>tree</code> "beispiel" (der wiederum einen <code>blob</code> enhält) und den <code>blob</code> "inhalt.txt".</p>
+<p>Der top-level <code>tree</code> referenziert den <code>tree</code> &quot;beispiel&quot; (der wiederum einen <code>blob</code> enhält) und den <code>blob</code> &quot;inhalt.txt&quot;.</p>
 <h1 id="snapshots-in-relation"><a class="header" href="#snapshots-in-relation">Snapshots in Relation</a></h1>
 <p><strong>Snapshots</strong> alleine bringen uns noch keinen Mehrwert. Erst wenn wir mehrere Snapshots in Relation setzten, kommen wir unserem Ziel eines VCS näher.</p>
 <h2 id="version-history-versionsgeschichte"><a class="header" href="#version-history-versionsgeschichte">Version history (Versionsgeschichte)</a></h2>
@@ -201,7 +201,7 @@ <h2 id="branches"><a class="header" href="#branches">Branches</a></h2>
 Dann arbeiten Alice und Bob parallel an dieser:</p>
 <p>Alice in src/datei.txt:</p>
 <pre><code>fn hello_world() {
-   print("Hello World")
+   print(&quot;Hello World&quot;)
 }
 
 fn main() {
@@ -210,15 +210,15 @@ <h2 id="branches"><a class="header" href="#branches">Branches</a></h2>
 </code></pre>
 <p>Bob in src/datei.txt:</p>
 <pre><code>fn hello(name: String) {
-   print("Hello" + name)
+   print(&quot;Hello&quot; + name)
 }
 
 fn main() {
-   hello("Bob")
+   hello(&quot;Bob&quot;)
 }
 </code></pre>
 <p><code>src</code>ist unser <code>top-level</code>-Ordner.
-Beide Personen schreiben an der selben Datei. Nur die Inhalte sind leicht unterschiedlich. Alice will das klassiche "Hello World" ausgegeben, während Bob lieber den eine Begrüßung mit Namen ausgeben möchte. Wir gehen davon aus dass sich nur diese Datei in dem Ordner <code>src</code> befindet. Wenn somit beide einen Commit (=Snapshot) erstellen haben diese die Form:</p>
+Beide Personen schreiben an der selben Datei. Nur die Inhalte sind leicht unterschiedlich. Alice will das klassiche &quot;Hello World&quot; ausgegeben, während Bob lieber den eine Begrüßung mit Namen ausgeben möchte. Wir gehen davon aus dass sich nur diese Datei in dem Ordner <code>src</code> befindet. Wenn somit beide einen Commit (=Snapshot) erstellen haben diese die Form:</p>
 <pre><code>src (tree)
 |
 +- datei.txt (blob, contents = ...)
@@ -261,7 +261,7 @@ <h1 id="merging-branches"><a class="header" href="#merging-branches">Merging Bra
 <p>Unser Modell müssen wir somit erweitern. Ein Knoten / Commit in einem Baum kann immer nur ein Parent erhalten. Unser Merge-Commit o-4 hat aber zwei Parents. In der Graphentheorie nennen wir diese neue Struktur einen <strong>DAG</strong> (Directed Asyclic Graph). Es hat nur eine wichtige Eigenschaft: Es gibt keine Zyklen. Das bedeutet, wenn wir den Verbindungen (Relations / Pointern) folgen, werden wir nie wieder an den selben Knoten zurückkommen.</p>
 <p>So schön und unkompliziert das Merging in der Theorie klingt, ist es in der Praxis leider nicht immer. Auch wenn git recht intelligent mit dem Zusammenführen von Änderungen umgeht, kann es immer noch zu Konflikten kommen, die dann manuell gelöst werden müssen. Hier fokusieren wir uns erstmal auf die Theorie und lernen später wie wir mit Konflikten umgehen.</p>
 <h1 id="rebasing-branches"><a class="header" href="#rebasing-branches">Rebasing Branches</a></h1>
-<p>Das einfache Zusammenführen von Branches ist nicht die einzige Möglichkeit Änderungen von der einen Branch mit der andern zu kombinieren. Git erlaubt uns auch das einfache "anhängen" von Commits aus einem Branch an einen anderen. Der Vorgang wird als <strong>Rebase</strong> bezeichnet.</p>
+<p>Das einfache Zusammenführen von Branches ist nicht die einzige Möglichkeit Änderungen von der einen Branch mit der andern zu kombinieren. Git erlaubt uns auch das einfache &quot;anhängen&quot; von Commits aus einem Branch an einen anderen. Der Vorgang wird als <strong>Rebase</strong> bezeichnet.</p>
 <p>Wenn wir nun also die Commits von Branch <code>feature_b</code> an Branch <code>feature_a</code> anhängen wollen, verändert sich unser Commit-Graph wie folgt:</p>
 <pre><code>o-1 &lt;--- o-2 (feature_a)
   ^
@@ -278,7 +278,7 @@ <h1 id="rebasing-branches"><a class="header" href="#rebasing-branches">Rebasing
 <p><code>feature_a</code> besteht nun aus den Commits o-1 und o-2, während <code>feature_b</code> nun aus o-1, o-2 und o-3 besteht. <code>feature_a</code> verändert sich somit nicht.
 Auch hier kann es selbstverständlich zu Konflikten kommen, die manuell gelöst werden müssen. Dazu später mehr.</p>
 <h1 id="commits"><a class="header" href="#commits">Commits</a></h1>
-<p>Du hast Commits bereits als "Snapshots" deiner Datein kennengelernt, dass ist nicht falsch, aber auch nicht ganz vollständig. Zusätzlich zu dem Zustand deiner Datein, speichert ein Commit noch Metainformationen wie:</p>
+<p>Du hast Commits bereits als &quot;Snapshots&quot; deiner Datein kennengelernt, dass ist nicht falsch, aber auch nicht ganz vollständig. Zusätzlich zu dem Zustand deiner Datein, speichert ein Commit noch Metainformationen wie:</p>
 <ul>
 <li>Autor</li>
 <li>Nachricht</li>