diff --git a/einfuehrung.html b/einfuehrung.html index 903a3fe..6c869b3 100644 --- a/einfuehrung.html +++ b/einfuehrung.html @@ -188,7 +188,7 @@

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.

  • -

    Code-Smells: 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.

    +

    Code-Smells: 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.

  • SCRUM: 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.

    diff --git a/git/branching_und_merging.html b/git/branching_und_merging.html index 4052a16..9a9264f 100644 --- a/git/branching_und_merging.html +++ b/git/branching_und_merging.html @@ -190,7 +190,7 @@

    Branching

    Die -b Flag steht hierbei für branch.

    -

    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 git branch tun.

    +

    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 git branch tun.

    $ git branch
 > * feature/1
   main
@@ -286,7 +286,7 @@ 
    Merge Conflic
 $ cat foo.txt
 > Hello Bob!
    -

    Wenn wir jetzt feature/1 in main mergen wollen, wird es zwangsweise zu einem Merge-Konflikt kommen, da nicht klar ist ob es "Hello Alice" oder "Hello Bob" heißen soll.

    +

    Wenn wir jetzt feature/1 in main mergen wollen, wird es zwangsweise zu einem Merge-Konflikt kommen, da nicht klar ist ob es "Hello Alice" oder "Hello Bob" heißen soll.

    $ git checkout main
 $ git merge feature/1
 > Auto-merging foo.txt
@@ -297,14 +297,14 @@ 
    Merge Conflic
 
    $ git status
 > 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 "git commit")
+    (use "git merge --abort" to abort the merge)
 
   Unmerged paths:
-    (use "git add <file>..." to mark resolution)
+    (use "git add <file>..." 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 "git add" and/or "git commit -a")
 
 
    
 
    Schauen wir uns mal an wie so ein Merge-Konflikt in der Datei aussieht:
    
@@ -321,7 +321,7 @@ 
    Merge Conflic

    Um git mitzuteilen, dass wir den Konflikt zu unserer Zufriedenheit gelöst haben, müssen wir die Datei foo.txt mit git add der Staging Area hinzufügen und dann einen ganz normalen Commit erstellen.

    $ git add foo.txt
-$ git commit -m "Merge feature/1 into main"
+$ git commit -m "Merge feature/1 into main"

    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 git merge --abort abbrechen. Damit werden alle Änderungen zurückgestzt als ob der Merge nie angefangen wurde.

    diff --git a/git/changing_history.html b/git/changing_history.html index a05c9e9..558dbff 100644 --- a/git/changing_history.html +++ b/git/changing_history.html @@ -214,7 +214,7 @@

    Checkout

    commit id: "656d54" type: HIGHLIGHT commit id: "de5234" -

    An sich kein Problem. Der HEAD zeigt jetzt auf den Commit 656d54 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?

    -

    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.

    +

    An sich kein Problem. Der HEAD zeigt jetzt auf den Commit 656d54 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?

    +

    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.

    -

    ‼️ 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 (git branch <branch_name>). 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 Help! I fucked up zu lesen.

    +

    ‼️ 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 (git branch <branch_name>). 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 Help! I fucked up zu lesen.

    -

    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 git checkout main.

    +

    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 git checkout main.

    Relative Commits

    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.

    @@ -575,7 +575,7 @@

    Squashing

    Working --> v3

    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.

    -
    $ git commit -m "Squashed commit"
+
    $ git commit -m "Squashed commit"
 
    
 
    gitGraph
 
@@ -592,22 +592,22 @@ 
    Stashing
    
 
    Beispiel:
    
 
    $ git status
 > Changes to be committed:
-    (use "git reset HEAD <file>..." to unstage)
+    (use "git reset HEAD <file>..." to unstage)
 
 	  modified:   bar.txt
 
   Changes not staged for commit:
-    (use "git add <file>..." to update what will be committed)
-    (use "git checkout -- <file>..." to discard changes in working directory)
+    (use "git add <file>..." to update what will be committed)
+    (use "git checkout -- <file>..." to discard changes in working directory)
 
 	  modified:   src/foo.txt
 
    
 
    Wir wollen jetzt Branch wechseln, aber die Änderungen in src/foo.txt sind noch nicht commit-bereit. Mit git-stash können wir die Änderungen temporär speichern.
    
 
    $ git stash
 > Saved working directory and index state \
-   "WIP on master: 049d078 Create index file"
+   "WIP on master: 049d078 Create index file"
   HEAD is now at 049d078 Create index file
-  (To restore them type "git stash apply")
+  (To restore them type "git stash apply")
 
    
 
    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 git status überprüfen.
    
 
    $ git status
@@ -620,19 +620,19 @@ 
    Stashing
    
 > stash@{0}: WIP on master: 049d078 Create index file
 > stash@{1}: WIP on master: 3923d03 Revert add file size
 
    
-
    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 -m angegeben werden (z.B. git stash -m "Meine Nachricht").
+
    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 -m angegeben werden (z.B. git stash -m "Meine Nachricht").
 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 Branching und Merging an.
    
 
    Um unseren Stash auf den aktuellen Working Tree und Staging Area anzuwenden verwenden wir git stash apply. Sollten wir nicht den letzten Stash anwenden wollen müssen wir die ID mit git stash apply stash@{1} angeben.
    
 
    $ git stash apply stash@{0}
 > On branch master
   Changes not staged for commit:
-    (use "git add <file>..." to update what will be committed)
-    (use "git checkout -- <file>..." to discard changes in working directory)
+    (use "git add <file>..." to update what will be committed)
+    (use "git checkout -- <file>..." 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 "git add" and/or "git commit -a")
 
    
 
    Wenn wir den Stash nicht mehr benötigen können wir ihn mit git stash drop stash@{0} löschen. Für alle Stashes funktioniert das mit git stash clear.
    
 
diff --git a/git/datenmodel.html b/git/datenmodel.html
index b0c4bd4..0a8c8ea 100644
--- a/git/datenmodel.html
+++ b/git/datenmodel.html
@@ -176,16 +176,16 @@ 
    Software Engineering / Teamprojekt Reference
    
                         
    Datenmodel
    
 
    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
    
 
    Snapshots / Commits
    
-
    Unser Modell beinhaltet einer Sammlung von Ordnern und Datein in einem "top-level" Ordner - ein Snapshot auch Commit genannt. Von git wird eine Datei auch als blob bezeichnet und ist letzendlich nur eine Sammlung aus Bytes. Das Dateiformat spielt somit keine Rolle. Ein Ordner wird als tree bezeichnet und ordnet einem Namen einen oder mehrere blobs und andere trees zu. Ordner können dementsprechend andere Ordner oder Datein enthalten und sind identisch vom Aufbau zu unserem Dateisystem. Zum Beispiel:
    
+
    Unser Modell beinhaltet einer Sammlung von Ordnern und Datein in einem "top-level" Ordner - ein Snapshot auch Commit genannt. Von git wird eine Datei auch als blob bezeichnet und ist letzendlich nur eine Sammlung aus Bytes. Das Dateiformat spielt somit keine Rolle. Ein Ordner wird als tree bezeichnet und ordnet einem Namen einen oder mehrere blobs und andere trees zu. Ordner können dementsprechend andere Ordner oder Datein enthalten und sind identisch vom Aufbau zu unserem Dateisystem. Zum Beispiel:
    
 
    <root> (tree)
 |
 +- beispiel (tree)
 |  |
-|  + hello.txt (blob, contents = "hello world")
+|  + hello.txt (blob, contents = "hello world")
 |
-+- inhalt.txt (blob, contents = "git ist super")
++- inhalt.txt (blob, contents = "git ist super")
 
    
-
    Der top-level tree referenziert den tree "beispiel" (der wiederum einen blob enhält) und den blob "inhalt.txt".
    
+
    Der top-level tree referenziert den tree "beispiel" (der wiederum einen blob enhält) und den blob "inhalt.txt".
    
 
    Snapshots in Relation
    
 
    Snapshots alleine bringen uns noch keinen Mehrwert. Erst wenn wir mehrere Snapshots in Relation setzten, kommen wir unserem Ziel eines VCS näher.
    
 
    Version history (Versionsgeschichte)
    
@@ -201,7 +201,7 @@ 
    Branches
    
 Dann arbeiten Alice und Bob parallel an dieser:
    
 
    Alice in src/datei.txt:
    
 
    fn hello_world() {
-   print("Hello World")
+   print("Hello World")
 }
 
 fn main() {
@@ -210,15 +210,15 @@ 
    Branches
    
 
    
 
    Bob in src/datei.txt:
    
 
    fn hello(name: String) {
-   print("Hello" + name)
+   print("Hello" + name)
 }
 
 fn main() {
-   hello("Bob")
+   hello("Bob")
 }
 
    
 
    srcist unser top-level-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 src befindet. Wenn somit beide einen Commit (=Snapshot) erstellen haben diese die Form:
    
+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 src befindet. Wenn somit beide einen Commit (=Snapshot) erstellen haben diese die Form:
    
 
    src (tree)
 |
 +- datei.txt (blob, contents = ...)
@@ -261,7 +261,7 @@ 
    Merging Bra
 
    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 DAG (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.
    
 
    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.
    
 
    Rebasing Branches
    
-
    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 Rebase bezeichnet.
    
+
    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 Rebase bezeichnet.
    
 
    Wenn wir nun also die Commits von Branch feature_b an Branch feature_a anhängen wollen, verändert sich unser Commit-Graph wie folgt:
    
 
    o-1 <--- o-2 (feature_a)
   ^
@@ -278,7 +278,7 @@ 
    Rebasing
 
    feature_a besteht nun aus den Commits o-1 und o-2, während feature_b nun aus o-1, o-2 und o-3 besteht. feature_a 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.
    
 
    Commits
    
-
    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:
    
+
    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:
    
 
 
    Konfiguration
    
 
    Die restliche Konfiguration läuft analog zu der auf Linux.
    
-
    $ git config --global user.name "Dein Name"
-$ git config --global user.email "deine@email.de"
+
    $ git config --global user.name "Dein Name"
+$ git config --global user.email "deine@email.de"
 $ git config --global init.defaultBranch main
 $ git config --global color.ui auto
 
    
@@ -335,26 +335,26 @@ 
    1. Git
 
    2. Konfiguration
    
 
    Folge nun der restlichen Konfiguartion hier
    
 
    Tipps
    
-
    Wenn ihr Windows benutzt und euch gewundert habt, warum ihr keine Dateien mit "."-Präfix seht (z.B. ".git", ".gitconfig", etc.) bzw. mit "."-Suffix (z.B. ".txt", ".mp4", etc.), dann könnt ihr das folgendermaßen ändern:
    
+
    Wenn ihr Windows benutzt und euch gewundert habt, warum ihr keine Dateien mit "."-Präfix seht (z.B. ".git", ".gitconfig", etc.) bzw. mit "."-Suffix (z.B. ".txt", ".mp4", etc.), dann könnt ihr das folgendermaßen ändern:
    
 
      
 
    1. 
-
      Sucht nach den "Explorer-Optionen" (entweder über das Suchfeld in den Einstellungen oder indem ihr mit dem Rechtsklick auf den Explorer klickt und auf "Eigenschaften" klickt).
      
+
      Sucht nach den "Explorer-Optionen" (entweder über das Suchfeld in den Einstellungen oder indem ihr mit dem Rechtsklick auf den Explorer klickt und auf "Eigenschaften" klickt).
      
 
      2. 
 
    2. 
-
      Klickt in dem neu geöffneten Fenster auf den Reiter "Ansicht"
      
+
      Klickt in dem neu geöffneten Fenster auf den Reiter "Ansicht"
      
 
      3. 
 
    3. 
-
      Deaktiviert "Erweiterungen bei bekannten Dateitypen ausblenden"
      
+
      Deaktiviert "Erweiterungen bei bekannten Dateitypen ausblenden"
      
 
      4. 
 
    4. 
-
      Wechselt die Option von "Ausgeblendete Dateien, Ordner oder Laufwerke nicht anzeigen" zu "Ausgeblendete Dateien, Ordner oder Laufwerke anzeigen"
      
+
      Wechselt die Option von "Ausgeblendete Dateien, Ordner oder Laufwerke nicht anzeigen" zu "Ausgeblendete Dateien, Ordner oder Laufwerke anzeigen"
      
 
      5. 
 
    
 
    Installation auf MacOS
    
 
    Homebrew
    
 
    Falls noch nicht der inoffiziellen (aber sehr verbreitete) Paketmanager homebrew auf deinem MacBook installiert ist, ist jetzt der Zeitpunkt. brew ermöglicht die einfache Installation von Software und wird dir noch oft in der Entwicklung auf MacOS begegnen.j
    
 
    Die Installation ist sehr simple. Kopiere den folgenden Befehl in dein Terminal und folgen den angezeigten Anweisungen.
    
-
    $ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
+
    $ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
 
    
 
    
 
    Das $ Zeichen wird verwendet um zu signalisieren, dass der folgende Befehl im Terminal auszuführen ist und ist nicht Teil des Befehls.
    
@@ -391,16 +391,16 @@ 
    2. Konfig
 
    Datenmodel
    
 
    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
    
 
    Snapshots / Commits
    
-
    Unser Modell beinhaltet einer Sammlung von Ordnern und Datein in einem "top-level" Ordner - ein Snapshot auch Commit genannt. Von git wird eine Datei auch als blob bezeichnet und ist letzendlich nur eine Sammlung aus Bytes. Das Dateiformat spielt somit keine Rolle. Ein Ordner wird als tree bezeichnet und ordnet einem Namen einen oder mehrere blobs und andere trees zu. Ordner können dementsprechend andere Ordner oder Datein enthalten und sind identisch vom Aufbau zu unserem Dateisystem. Zum Beispiel:
    
+
    Unser Modell beinhaltet einer Sammlung von Ordnern und Datein in einem "top-level" Ordner - ein Snapshot auch Commit genannt. Von git wird eine Datei auch als blob bezeichnet und ist letzendlich nur eine Sammlung aus Bytes. Das Dateiformat spielt somit keine Rolle. Ein Ordner wird als tree bezeichnet und ordnet einem Namen einen oder mehrere blobs und andere trees zu. Ordner können dementsprechend andere Ordner oder Datein enthalten und sind identisch vom Aufbau zu unserem Dateisystem. Zum Beispiel:
    
 
    <root> (tree)
 |
 +- beispiel (tree)
 |  |
-|  + hello.txt (blob, contents = "hello world")
+|  + hello.txt (blob, contents = "hello world")
 |
-+- inhalt.txt (blob, contents = "git ist super")
++- inhalt.txt (blob, contents = "git ist super")
 
    
-
    Der top-level tree referenziert den tree "beispiel" (der wiederum einen blob enhält) und den blob "inhalt.txt".
    
+
    Der top-level tree referenziert den tree "beispiel" (der wiederum einen blob enhält) und den blob "inhalt.txt".
    
 
    Snapshots in Relation
    
 
    Snapshots alleine bringen uns noch keinen Mehrwert. Erst wenn wir mehrere Snapshots in Relation setzten, kommen wir unserem Ziel eines VCS näher.
    
 
    Version history (Versionsgeschichte)
    
@@ -416,7 +416,7 @@ 
    Branches
    
 Dann arbeiten Alice und Bob parallel an dieser:
    
 
    Alice in src/datei.txt:
    
 
    fn hello_world() {
-   print("Hello World")
+   print("Hello World")
 }
 
 fn main() {
@@ -425,15 +425,15 @@ 
    Branches
    
 
    
 
    Bob in src/datei.txt:
    
 
    fn hello(name: String) {
-   print("Hello" + name)
+   print("Hello" + name)
 }
 
 fn main() {
-   hello("Bob")
+   hello("Bob")
 }
 
    
 
    srcist unser top-level-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 src befindet. Wenn somit beide einen Commit (=Snapshot) erstellen haben diese die Form:
    
+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 src befindet. Wenn somit beide einen Commit (=Snapshot) erstellen haben diese die Form:
    
 
    src (tree)
 |
 +- datei.txt (blob, contents = ...)
@@ -476,7 +476,7 @@ 
    Merging Bra
 
    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 DAG (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.
    
 
    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.
    
 
    Rebasing Branches
    
-
    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 Rebase bezeichnet.
    
+
    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 Rebase bezeichnet.
    
 
    Wenn wir nun also die Commits von Branch feature_b an Branch feature_a anhängen wollen, verändert sich unser Commit-Graph wie folgt:
    
 
    o-1 <--- o-2 (feature_a)
   ^
@@ -493,7 +493,7 @@ 
    Rebasing
 
    feature_a besteht nun aus den Commits o-1 und o-2, während feature_b nun aus o-1, o-2 und o-3 besteht. feature_a 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.
    
 
    Commits
    
-
    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:
    
+
    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:
    
 
      
 
    • Autor
      • 
 
    • Nachricht
      • 
@@ -596,7 +596,7 @@ 
      Repositor
 
       $ git clone git@github.com:leonfuss/se_workshop_example.git /pfad/zu/deinem/ordner
 
      
 
      Staging und Working Area
      
-
      Bis jetzt hat unser Datenmodell sowie unser frisch erstelltes Repository noch keinen Bezug zu unseren "normalen" Dateien, so wie wir sie aus unserem Finder oder Explorer kennen. Wir kennen unseren Commit Tree und unser Dateisystem, aber wie stehen diese miteinander in Interaktion?
      
+
      Bis jetzt hat unser Datenmodell sowie unser frisch erstelltes Repository noch keinen Bezug zu unseren "normalen" Dateien, so wie wir sie aus unserem Finder oder Explorer kennen. Wir kennen unseren Commit Tree und unser Dateisystem, aber wie stehen diese miteinander in Interaktion?
      
 
      Working Area (Working Tree)
      
 
      Das ganz normale Dateisystem in git wird auch als Working Area bezeichnet. Wie der Name bereits indikiert, ist dies der Bereich, in dem wir wie gewohnt arbeiten. Wir erstellen Datein, löschen Datein, ändern Datein, etc. Hier ist also nahezu alles gleich - mit oder ohne git.
      
 
      Staging Area
      
@@ -620,11 +620,11 @@ 
      Staging Area
    
 
    Was sehen wir hier? Es existiert der Branch main und unser HEAD befindet sich akutell dort. Jedoch gibt es noch keinen Commits in unserem Repository.
    
 
    Git zeigt uns aber schon an, dass es Datein gibt, die noch nicht getrackt - noch nie in einem Commit festgehalten - wurden
    
@@ -651,7 +651,7 @@ 
    Staging AreaCommit
    
  create mode 100644 src/foo/foo.txt
 
    
 
    Nachdem ihr den Befehl ausgeführt habt, öffnet sich ein Editor. Hier könnt ihr eine Commit Message schreiben. Diese sollte kurz und prägnant sein und beschreiben, was ihr in diesem Commit gemacht habt. Wenn ihr den Editor schließt, wird der Commit erstellt. Solltet ihr nur eine kurze Nachricht haben können wir diese auch direkt in der Shell hinzufügen:
    
-
      $ git commit -m "Initial commit"
+
      $ git commit -m "Initial commit"
   > [main (root-commit) 3adf051] Initial commit
    3 files changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 config.toml
@@ -843,13 +843,13 @@ 
    Checkout
    
   commit id: "656d54" type: HIGHLIGHT
   commit id: "de5234"
 
    
-
    An sich kein Problem. Der HEAD zeigt jetzt auf den Commit 656d54 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?
    
-
    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.
    
+
    An sich kein Problem. Der HEAD zeigt jetzt auf den Commit 656d54 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?
    
+
    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.
    
 
    
-
    ‼️ 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 (git branch <branch_name>). 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 Help! I fucked up zu lesen.
    
+
    ‼️ 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 (git branch <branch_name>). 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 Help! I fucked up zu lesen.
    
 
    
 
    
-
    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 git checkout main.
    
+
    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 git checkout main.
    
 
    
 
    Relative Commits
    
 
    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.
    
@@ -1094,7 +1094,7 @@ 
    Squashing
    
     Working --> v3
 
    
 
    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.
    
-
    $ git commit -m "Squashed commit"
+
    $ git commit -m "Squashed commit"
 
    
 
    gitGraph
 
@@ -1111,22 +1111,22 @@ 
    Stashing
    
 
    Beispiel:
    
 
    $ git status
 > Changes to be committed:
-    (use "git reset HEAD <file>..." to unstage)
+    (use "git reset HEAD <file>..." to unstage)
 
 	  modified:   bar.txt
 
   Changes not staged for commit:
-    (use "git add <file>..." to update what will be committed)
-    (use "git checkout -- <file>..." to discard changes in working directory)
+    (use "git add <file>..." to update what will be committed)
+    (use "git checkout -- <file>..." to discard changes in working directory)
 
 	  modified:   src/foo.txt
 
    
 
    Wir wollen jetzt Branch wechseln, aber die Änderungen in src/foo.txt sind noch nicht commit-bereit. Mit git-stash können wir die Änderungen temporär speichern.
    
 
    $ git stash
 > Saved working directory and index state \
-   "WIP on master: 049d078 Create index file"
+   "WIP on master: 049d078 Create index file"
   HEAD is now at 049d078 Create index file
-  (To restore them type "git stash apply")
+  (To restore them type "git stash apply")
 
    
 
    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 git status überprüfen.
    
 
    $ git status
@@ -1139,19 +1139,19 @@ 
    Stashing
    
 > stash@{0}: WIP on master: 049d078 Create index file
 > stash@{1}: WIP on master: 3923d03 Revert add file size
 
    
-
    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 -m angegeben werden (z.B. git stash -m "Meine Nachricht").
+
    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 -m angegeben werden (z.B. git stash -m "Meine Nachricht").
 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 Branching und Merging an.
    
 
    Um unseren Stash auf den aktuellen Working Tree und Staging Area anzuwenden verwenden wir git stash apply. Sollten wir nicht den letzten Stash anwenden wollen müssen wir die ID mit git stash apply stash@{1} angeben.
    
 
    $ git stash apply stash@{0}
 > On branch master
   Changes not staged for commit:
-    (use "git add <file>..." to update what will be committed)
-    (use "git checkout -- <file>..." to discard changes in working directory)
+    (use "git add <file>..." to update what will be committed)
+    (use "git checkout -- <file>..." 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 "git add" and/or "git commit -a")
 
    
 
    Wenn wir den Stash nicht mehr benötigen können wir ihn mit git stash drop stash@{0} löschen. Für alle Stashes funktioniert das mit git stash clear.
    
 
    Help! I fucked up
    
@@ -1200,7 +1200,7 @@ 
    Branching
    
 
    
 
    Die -b Flag steht hierbei für branch.
    
 
    
-
    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 git branch tun.
    
+
    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 git branch tun.
    
 
    $ git branch
 > * feature/1
   main
@@ -1296,7 +1296,7 @@ 
    Merge Conflic
 $ cat foo.txt
 > Hello Bob!
 
    
-
    Wenn wir jetzt feature/1 in main mergen wollen, wird es zwangsweise zu einem Merge-Konflikt kommen, da nicht klar ist ob es "Hello Alice" oder "Hello Bob" heißen soll.
    
+
    Wenn wir jetzt feature/1 in main mergen wollen, wird es zwangsweise zu einem Merge-Konflikt kommen, da nicht klar ist ob es "Hello Alice" oder "Hello Bob" heißen soll.
    
 
    $ git checkout main
 $ git merge feature/1
 > Auto-merging foo.txt
@@ -1307,14 +1307,14 @@ 
    Merge Conflic
 
    $ git status
 > 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 "git commit")
+    (use "git merge --abort" to abort the merge)
 
   Unmerged paths:
-    (use "git add <file>..." to mark resolution)
+    (use "git add <file>..." 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 "git add" and/or "git commit -a")
 
 
    
 
    Schauen wir uns mal an wie so ein Merge-Konflikt in der Datei aussieht:
    
@@ -1331,7 +1331,7 @@ 
    Merge Conflic
 
    
 
    Um git mitzuteilen, dass wir den Konflikt zu unserer Zufriedenheit gelöst haben, müssen wir die Datei foo.txt mit git add der Staging Area hinzufügen und dann einen ganz normalen Commit erstellen.
    
 
    $ git add foo.txt
-$ git commit -m "Merge feature/1 into main"
+$ git commit -m "Merge feature/1 into main"
 
    
 
    
 
    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 git merge --abort abbrechen. Damit werden alle Änderungen zurückgestzt als ob der Merge nie angefangen wurde.
    
@@ -1451,7 +1451,7 @@ 
    Der WorkflowIhr habt eine klare Vorstellung, was ihr implementieren oder ändern wollt. Die Aufgabe sollte in sich geschlossen sein und nicht zu groß.
    • -

    "nicht zu groß" ist ein sehr subjektiver Begriff. Aber für euer Teamprojekt könnt ihr euch an einer groben Faustregel orientieren: Wenn ihr vorraussichtlich mehr als 4-5 Stunden braucht um die Aufgabe zu erledigen, ist sie vermutlich zu groß. Hier solltet ihr sie in deutlich fassbare Aufgaben unterteilen.

    +

    "nicht zu groß" ist ein sehr subjektiver Begriff. Aber für euer Teamprojekt könnt ihr euch an einer groben Faustregel orientieren: Wenn ihr vorraussichtlich mehr als 4-5 Stunden braucht um die Aufgabe zu erledigen, ist sie vermutlich zu groß. Hier solltet ihr sie in deutlich fassbare Aufgaben unterteilen.

    1. @@ -1768,7 +1768,7 @@

      Der WorkflowAnforderungen

      Bevor es losgeht, müssen wir uns überlegen, was genau wir eigentlich schreiben wollen. Hier reicht nicht nur eine grobe Idee, sondern es sollten ganz explizit die Use-Cases festgelegt werden.

      Beispiel

      -

      "Wir schreiben eine App die es ermöglicht Rezepte zu verwalten."

      +

      "Wir schreiben eine App die es ermöglicht Rezepte zu verwalten."

      Das ist eine grobe Idee und sicher nicht genug um loszulegen. Arbeitet ganz explizite Use-Cases aus

      @@ -1871,7 +1871,7 @@

      Implementieru // checke ob der Dateipfad existiert und eine Datei ist fn is_file() -> bool { - match std::fs::metadata("file.txt") { + match std::fs::metadata("file.txt") { Ok(it) => it.is_file(), Err(_) => false, } @@ -2019,7 +2019,7 @@

      Beispiel

      @Override public void turnOnEngine() { - throw new AssertionError("There is no engine!"); + throw new AssertionError("There is no engine!"); } @Override @@ -2061,7 +2061,7 @@

      Beispiel

      @Override public void fly() { - throw new UnsupportedOperationException("This vehicle cannot fly."); + throw new UnsupportedOperationException("This vehicle cannot fly."); } }       @@ -2138,8 +2138,8 @@

      Beispiel

      public void setCurrentConditions(String weatherDescription) { this.currentConditions = weatherDescription; - if (weatherDescription == "rainy") { - emailer.sendEmail("It is rainy"); + if (weatherDescription == "rainy") { + emailer.sendEmail("It is rainy"); } } } @@ -2161,21 +2161,21 @@

      Beispiel

      public void setCurrentConditions(String weatherDescription) { this.currentConditions = weatherDescription; - if (weatherDescription == "rainy") { - notifier.alertWeatherConditions("It is rainy"); + if (weatherDescription == "rainy") { + notifier.alertWeatherConditions("It is rainy"); } } } class Emailer implements Notifier { public void alertWeatherConditions(String weatherDescription) { - System.out.println("Email sent: " + weatherDescription); + System.out.println("Email sent: " + weatherDescription); } } class SMS implements Notifier { public void alertWeatherConditions(String weatherDescription) { - System.out.println("SMS sent: " + weatherDescription); + System.out.println("SMS sent: " + weatherDescription); } }       diff --git a/searcher.js b/searcher.js index dc03e0a..d2b0aee 100644 --- a/searcher.js +++ b/searcher.js @@ -316,7 +316,7 @@ window.search = window.search || {}; // Eventhandler for keyevents on `document` function globalKeyHandler(e) { - if (e.altKey || e.ctrlKey || e.metaKey || e.shiftKey || e.target.type === 'textarea' || e.target.type === 'text' || !hasFocus() && /^(?:input|select|textarea)$/i.test(e.target.nodeName)) { return; } + if (e.altKey || e.ctrlKey || e.metaKey || e.shiftKey || e.target.type === 'textarea' || e.target.type === 'text') { return; } if (e.keyCode === ESCAPE_KEYCODE) { e.preventDefault(); diff --git a/softwareentwicklung.html b/softwareentwicklung.html index 7f1aea4..b5b8039 100644 --- a/softwareentwicklung.html +++ b/softwareentwicklung.html @@ -180,7 +180,7 @@

      Softw

      Anforderungen

      Bevor es losgeht, müssen wir uns überlegen, was genau wir eigentlich schreiben wollen. Hier reicht nicht nur eine grobe Idee, sondern es sollten ganz explizit die Use-Cases festgelegt werden.

      Beispiel

      -

      "Wir schreiben eine App die es ermöglicht Rezepte zu verwalten."

      +

      "Wir schreiben eine App die es ermöglicht Rezepte zu verwalten."

      Das ist eine grobe Idee und sicher nicht genug um loszulegen. Arbeitet ganz explizite Use-Cases aus

      @@ -283,7 +283,7 @@

      Implementieru // checke ob der Dateipfad existiert und eine Datei ist fn is_file() -> bool { - match std::fs::metadata("file.txt") { + match std::fs::metadata("file.txt") { Ok(it) => it.is_file(), Err(_) => false, } diff --git a/solid/dip.html b/solid/dip.html index 605c697..938012e 100644 --- a/solid/dip.html +++ b/solid/dip.html @@ -190,8 +190,8 @@

      Dep public void setCurrentConditions(String weatherDescription) { this.currentConditions = weatherDescription; - if (weatherDescription == "rainy") { - emailer.sendEmail("It is rainy"); + if (weatherDescription == "rainy") { + emailer.sendEmail("It is rainy"); } } } @@ -213,21 +213,21 @@

      Dep public void setCurrentConditions(String weatherDescription) { this.currentConditions = weatherDescription; - if (weatherDescription == "rainy") { - notifier.alertWeatherConditions("It is rainy"); + if (weatherDescription == "rainy") { + notifier.alertWeatherConditions("It is rainy"); } } } class Emailer implements Notifier { public void alertWeatherConditions(String weatherDescription) { - System.out.println("Email sent: " + weatherDescription); + System.out.println("Email sent: " + weatherDescription); } } class SMS implements Notifier { public void alertWeatherConditions(String weatherDescription) { - System.out.println("SMS sent: " + weatherDescription); + System.out.println("SMS sent: " + weatherDescription); } } diff --git a/solid/isp.html b/solid/isp.html index dd01d6a..95ce76b 100644 --- a/solid/isp.html +++ b/solid/isp.html @@ -205,7 +205,7 @@

      Beispiel

      @Override public void fly() { - throw new UnsupportedOperationException("This vehicle cannot fly."); + throw new UnsupportedOperationException("This vehicle cannot fly."); } } diff --git a/solid/lsp.html b/solid/lsp.html index 5d08d66..f5165e7 100644 --- a/solid/lsp.html +++ b/solid/lsp.html @@ -209,7 +209,7 @@

      Lisko @Override public void turnOnEngine() { - throw new AssertionError("There is no engine!"); + throw new AssertionError("There is no engine!"); } @Override diff --git a/terminal.html b/terminal.html index da2797d..cb8c726 100644 --- a/terminal.html +++ b/terminal.html @@ -182,13 +182,13 @@

      Was

      Terminal und Shell werden oft synonym verwndet auch wenn sie nicht ganz das gleiche sind. Das Terminal ist ein Programm, das es ermöglicht, mit einer Shell zu interagieren. Die Shell ist das eigentliche Programm, das die Befehle ausführt.

      -

      In unserem Workshop liegt der Fokus auf der Bourne Again SHell, kurz "bash". Sie ist eine der am weitesten verbreiteten Shells und ihre Syntax ist ähnlich zu vielen anderern Shells. Um eine Shell-Prompt zu öffnen (in der du Befehle eingeben kannst), benötigst du zunächst ein Terminal. Auf deinem Gerät ist wahrscheinlich bereits eines installiert. (Nutzte auf Windows das Programm "Git Bash")

      +

      In unserem Workshop liegt der Fokus auf der Bourne Again SHell, kurz "bash". Sie ist eine der am weitesten verbreiteten Shells und ihre Syntax ist ähnlich zu vielen anderern Shells. Um eine Shell-Prompt zu öffnen (in der du Befehle eingeben kannst), benötigst du zunächst ein Terminal. Auf deinem Gerät ist wahrscheinlich bereits eines installiert. (Nutzte auf Windows das Programm "Git Bash")

      Die Shell nutzen

      Wenn du dein Terminal öffnest, siehst du eine prompt die so oder ähnlich aussieht:

      arch:~$
      -

      "arch" ist der Name des Computers, "~" ist das cwd (current working directory) bzw. aktuelles Verzeichnis und "$" signalisiert, dass du als normaler Benutzer angemeldet bist. (Adminastrator hat ein "#"). -Das "~" ist eine Abkürzung für dein Home-Verzeichnis. auf Unix-Systemen ist das /home/deinBenutzername/ und auf Windows C:\Users\deinBenutzername\.

      +

      "arch" ist der Name des Computers, "~" ist das cwd (current working directory) bzw. aktuelles Verzeichnis und "$" signalisiert, dass du als normaler Benutzer angemeldet bist. (Adminastrator hat ein "#"). +Das "~" ist eine Abkürzung für dein Home-Verzeichnis. auf Unix-Systemen ist das /home/deinBenutzername/ und auf Windows C:\Users\deinBenutzername\.

      Im Laufe des Workshops werden immer wieder Befehle gezeigt, die du in deinem Terminal ausführen kannst. Sie haben immer die gleiche Form:

      $ cat datei.txt