Übung: Zusammenarbeit mithilfe eines freigegebenen Repositorys

10 Minuten

Das direkte Pullen aus dem Repository eines anderen Benutzers funktioniert, vorausgesetzt, Sie befinden sich beide im gleichen Netzwerk. Es ist jedoch ein umständlicher Prozess, und meistens befinden sich viele Mitarbeiter nicht im selben Netzwerk. Es ist besser, ein zentrales Repository einzurichten, auf das alle Mitarbeiter per Pull zugreifen und von dem sie Daten per Push abrufen können.

Wenn Sie Ihrem befreundeten Entwickler Bob von Ihrem Projekt erzählen und Bob sich beteiligen möchte, entscheiden Sie sich genau dafür: Sie richten ein zentrales Repository ein, das auch Bare-Repository genannt wird.

Erstellen eines Bare-Repositorys

Sie benötigen ein Repository, das keine Arbeitsstruktur aufweist. Ein Bare-Repository hat mehrere Vorteile gegenüber einer Arbeitsstruktur:

Ohne Arbeitsstruktur kann jeder Änderungen per Push übertragen und muss sich keine Gedanken darüber machen, welcher Branch ausgecheckt ist.
Git kann problemlos erkennen, wenn ein anderer Benutzer Änderungen gepusht hat, die mit Ihren in Konflikt stehen.
Ein freigegebenes Repository kann eine beliebige Anzahl von Entwicklern umfassen. Bei einem Bare-Repository müssen Sie nur über das freigegebene Repository Bescheid wissen, und nicht über all die anderen Mitwirkenden, von denen Sie vielleicht pullen möchten.
Wenn Sie das freigegebene Repository auf einem Server platzieren, auf den alle Beteiligten zugreifen können, müssen Sie sich keine Gedanken um Firewalls und Berechtigungen machen.
Sie müssen auf dem Server keine Konten trennen, da Git nachverfolgt, von wem welcher Commit durchgeführt wurde. (Die Millionen von GitHub-Benutzern teilen sich alle das git-Konto. Jeder verwendet das kryptografische Netzwerkprotokoll Secure Shell (SSH), und die Benutzer werden durch ihre öffentlichen Schlüssel unterschieden.)

Das Erstellen eines Bare-Repositorys für die Zusammenarbeit ist ganz einfach:

Erstellen Sie ein neues Verzeichnis mit dem Namen Shared.git auf derselben Ebene wie die Verzeichnisse Alice und Cats, um darin das Bare-Repository zu speichern:
```
cd ..
mkdir Shared.git
cd Shared.git
```
Der Name des Verzeichnisses ist nicht wichtig, aber wir werden es in diesen Übungen als das Verzeichnis Shared.git oder einfach als das freigegebene Verzeichnis („shared“) bezeichnen.

Die Benennung des Verzeichnisses als Shared.git folgt der langjährigen Tradition, Bare-Repositorys einen Namen zu geben, der mit .git endet, um sie von Arbeitsstrukturen zu unterscheiden. Es handelt sich um eine Konvention und ist keine Voraussetzung.
Verwenden Sie nun den folgenden Befehl, um ein Bare-Repository im freigegebenen Verzeichnis zu erstellen:
```
git init --bare
```
Wenn ein Repository noch leer ist, git checkout kann der Befehl nicht zum Festlegen des Namens des Standardbranchs verwendet werden. Um diese Aufgabe zu erfüllen, können Sie den Branch HEAD so ändern, dass er auf einen anderen Branch zeigt, in diesem Fall der Branch main:
```
git symbolic-ref HEAD refs/heads/main
```
Im nächsten Schritt platzieren Sie die Inhalte Ihres Repositorys im freigegebenen Repository. Verwenden Sie diese Befehle, um zum Projektverzeichnis mit Ihrem Repository zurückzukehren, ein origin-Remoterepository zu erstellen und einen ersten Pushvorgang auszuführen:
```
cd ../Cats
git remote add origin ../Shared.git
git push origin main
```

Überprüfen Sie die Ausgabe. Die Ausgabe sollte den Erfolg bestätigen:

Counting objects: 12, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (12/12), 1.07 KiB | 0 bytes/s, done.
Total 12 (delta 1), reused 0 (delta 0)
To ../Shared.git
 * [new branch]      main -> main

Sie möchten, dass push und pull standardmäßig den Branch main von origin verwenden, als ob Sie Ihr Repository direkt durch Klonen erstellt hätten. Dazu müssen Sie zunächst Git darüber informieren, welcher Branch nachverfolgt werden soll.
```
git branch --set-upstream-to origin/main
```
Überprüfen Sie auf diese Ausgabe:
```
branch 'main' set up to track 'origin/main'.
```
Sie würden eine Fehlermeldung von Git erhalten, wenn Sie diesen Befehl vor dem ersten Pushvorgang ausführen, da das neue Repository noch keine Branchs enthielt. Git kann keinen Branch nachverfolgen, der nicht vorhanden ist. Alles, was Git im Hintergrund macht, ist in .git/refs/remotes/origin nach einer Datei namens trunk zu suchen.

Einrichten für Projektmitarbeiter

Im nächsten Schritt klont Bob das Bare-Repository. Anschließend legt Alice den Ursprung in ihrem Repository so fest, dass das freigegebene Repository für Push- und Pullvorgänge verwendet wird.

Erstellen Sie ein Verzeichnis mit dem Namen Bob, das ein gleichgeordnetes Verzeichnis des Projektverzeichnisses ist, und wechseln Sie dann in das Verzeichnis Bob:
```
cd ..
mkdir Bob
cd Bob
```
Klonen Sie nun das freigegebene Repository (stellen Sie sicher, dass Sie den Punkt am Ende des Befehls einschließen):
```
git clone ../Shared.git .
```
Zurzeit wird das Repository von Alice konfiguriert, um zu ihrem eigenen Repository pushen oder daraus pullen zu können. Verwenden Sie die folgenden Befehle, um in das Verzeichnis Alice zu wechseln und origin so zu ändern, dass es auf das freigegebene Repository verweist:
```
cd ../Alice
git remote set-url origin ../Shared.git
```

Beginn der Zusammenarbeit

Nachdem die Einrichtung für „Bob“ erfolgt ist, sodass Bob auf der Website arbeiten kann, entscheidet sich Bob dazu, unten auf der Seite eine Fußzeile hinzuzufügen. Wir agieren jetzt als Bob und Alice und lernen die Grundlagen der Zusammenarbeit kennen.

Beginnen Sie, indem Sie in das Verzeichnis Bob wechseln und als Bob arbeiten:

cd ../Bob
git config user.name Bob
git config user.email bob@contoso.com

Öffnen Sie index.html mithilfe von code index.html, und ersetzen Sie das <hr>-Element durch die folgende Zeile (am Ende des <body>-Elements):
```
<footer><hr>Copyright (c) 2021 Contoso Cats</footer>
```
Speichern Sie die Datei dann, und schließen Sie den Editor.
Comitten Sie die Änderungen, und pushen Sie sie zum Remoterepository „Origin“:
```
git commit -a -m "Put a footer at the bottom of the page"
git push
```

Überprüfen Sie die Ausgabe. Wenn Sie eine Warnung wie im folgenden Beispiel sehen, machen Sie sich keine Sorgen. Diese Warnung informiert Benutzer lediglich über eine Änderung des Standardverhaltens von Git. Wenn Sie sicherstellen möchten, dass diese Warnung nicht noch mal angezeigt wird, können Sie git config --global push.default simple ausführen.

warning: push.default is unset; its implicit value has changed in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the traditional behavior, use:

  git config --global push.default matching

To squelch this message and adopt the new behavior now, use:

  git config --global push.default simple

When push.default is set to 'matching', git will push local branches
to the remote branches that already exist with the same name.

Since Git 2.0, Git defaults to the more conservative 'simple'
behavior, which only pushes the current branch to the corresponding
remote branch that 'git pull' uses to update the current branch.

See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)

Bob und Alice bearbeiten die Website gleichzeitig. Alice entscheidet sich, eine Navigationsleiste zur Seite hinzuzufügen. Dafür muss Alice zwei Dateien ändern: index.html und site.css. Beginnen Sie, indem Sie zum Verzeichnis Alice zurückkehren:
```
cd ../Alice
```
Öffnen Sie nun die Datei index.html, und fügen Sie die folgende Zeile direkt nach dem Tag <body> in Zeile 8 ein:
```
<nav><a href="./index.html">home</a></nav>
```
Speichern Sie die Datei dann, und schließen Sie den Editor.
Öffnen Sie dann site.css im Order CSS mithilfe von code CSS/site.css, und fügen Sie am unteren Rand die folgende Zeile ein:
```
nav { background-color: #C0D8DF; }
```
Speichern Sie die Datei, und schließen Sie den Editor.
Nehmen wir nun an, dass Alice eine E-Mail von Bob erhält, in der er sie über Änderungen an der Website informiert. Alice beschließt, Bobs Änderungen zu pullen, bevor Sie ihre eigenen committet. (Wenn sie ihre Änderungen bereits committet hätte, würde ein anderes Problem entstehen, auf das in einem anderen Modul eingegangen wird.) Alice führt diesen Befehl aus:
```
git pull
```

Überprüfen Sie die Ausgabe. Aus der Ausgabe sieht es so aus, als hätte Git ein Problem verhindert:

remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../Shared
   843d142..2cf6cbf  main     -> origin/main
Updating 843d142..2cf6cbf
error: Your local changes to the following files would be overwritten by merge:
        index.html
Please commit your changes or stash them before you can merge.
Aborting

Git warnt davor, dass der Pull die Version von Alice von index.html überschreiben würde und sie ihre Änderungen verlieren würde. Das liegt daran, dass Bob index.html auch geändert hat. Hätte Alice die Datei index.html nicht geändert, hätte Git die Zusammenführung committet.

Verwenden Sie einen git diff-Befehl, um zu sehen, welche Änderungen Bob an index.html vorgenommen hat:
```
git diff origin -- index.html
```
Überprüfen Sie die Ausgabe. Aus der Ausgabe geht hervor, dass sich die Änderungen von Alice und Bob nicht überlappen. Nun kann Alice ihre Änderungen stashen.

git stash speichert den Zustand der Arbeitsstruktur und des Index, indem es ein paar temporäre Commits erstellt. Betrachten Sie den Stash als eine Möglichkeit, Ihre aktuelle Arbeit zu speichern, während Sie etwas anderes tun, ohne einen „realen“ Commit zu erstellen oder Ihren Repositoryverlauf zu beeinflussen.

In Wirklichkeit hätte Alice ihre Veränderungen stashen oder committen sollen, bevor sie versucht, einen Pull auszuführen. Das Pullen in eine „geänderte“ Arbeitsstruktur ist riskant, weil dort Schäden angerichtet werden können, die nicht ohne Weiteres beseitigt werden können.

Verwenden Sie den folgenden Befehl, um die Änderungen von Alice zu stashen:
```
git stash
```

Überprüfen Sie die Ausgabe. Es sollte wie im folgenden Beispiel aussehen:

Saved working directory and index state WIP on main: 95bbc3b Change background color to light blue
HEAD is now at 95bbc3b Change background color to light blue

Jetzt kann Alice einen Pullvorgang durchführen, nach dem sie dann einen Stash per Pop entfernen kann, der als Stapel organisiert ist. (git stash stellt tatsächlich die Kurznotation von git stash push dar. Es ist ähnlich wie der Stapel, auf den man Rechnungen legt, die man noch nicht bezahlt hat.) Führen Sie die folgenden Befehle aus:
```
git pull
git stash pop
```
Durch Entfernen des Stashs per Pop werden die Änderungen zusammengeführt. Wenn die Änderungen überlappen, tritt möglicherweise ein Konflikt auf. Wie Sie diese Situationen lösen können, erfahren Sie in einem fortgeschrittenen Git-Modul von Microsoft Learn.
Überprüfen Sie die Ausgabe. Alice sollte die folgende Ausgabe angezeigt werden, die sie darüber informiert, dass die Zusammenführung erfolgreich war und Ihre Änderungen wiederhergestellt, aber noch nicht für den Commitvorgang bereitgestellt wurden:
```
Auto-merging index.html
On branch main
Your branch is up-to-date with 'origin/main'.
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)

        modified:   CSS/site.css
        modified:   index.html

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (0cfb7b75d56611d9fc6a6ab660a51f5582b8d9c5)
```
An diesem Punkt kann Alice weiterarbeiten oder einfach ihre Änderungen committen und pushen. Nehmen Sie als Alice eine weitere Änderung vor, indem Sie den Fußzeilen den gleichen Stil wie den Navigationsleisten zuweisen.
Öffnen Sie site.css im Ordner CSS, und ersetzen Sie die dritte Zeile (diejenige, die Stile für die <nav>-Elemente anwendet) durch diese freigegebene CSS-Regel. Speichern Sie dann wie üblich die Änderungen, und schließen Sie den Editor.
```
nav, footer { background-color: #C0D8DF; }
```
Committen Sie jetzt die Änderungen und pushen Sie diese in das freigegebene Repository:
```
git commit -a -m "Stylize the nav bar"
git push
```
Die aktualisierte Seite ist jetzt im freigegebenen Repository.
Beenden Sie die Schritte, indem Sie zum Projektverzeichnis zurückkehren, und führen Sie einen Pull durch:
```
cd ../Cats
git pull
```

Öffnen Sie index.html (die Datei im Projektverzeichnis), um zu überprüfen, ob die Änderungen von Bob und auch von Alice in Ihrem lokalen Repository vorhanden sind. Stellen Sie sicher, dass index.html über den neuesten Code verfügt:

<!DOCTYPE html>
<html>
  <head>
    <meta charset='UTF-8'>
    <title>Our Feline Friends</title>
    <link rel="stylesheet" href="CSS/site.css">
  </head>
  <body>
    <nav><a href="./index.html">home</a></nav>
    <h1>Our Feline Friends</h1>
    <p>Eventually we will put cat pictures here.</p>
    <footer><hr>Copyright (c) 2021 Contoso Cats</footer>
  </body>
</html>

Im Moment werden Ihr Repository und das von Alice synchronisiert, aber das Repository von Bob nicht. Schließen Sie den Schritt ab, indem Sie Bob auch auf den neuesten Stand bringen:
```
cd ../Bob
git pull
```

Alle drei Repositorys befinden sich nun in der Ausrichtung. Das freigegebene Repository ist die einzige vertrauenswürdige Quelle für alle Benutzer. Sämtliche Push- und Pullvorgänge werden an das freigegebene Repository weitergeleitet.

Wenn Sie neugierig sind, wie die Website aussieht, finden Sie im Folgenden eine Vorschau:

Screenshot der gerenderten Katzen-Website.

Wenn Sie möchten, können Sie Ihre Dateien herunterladen, um sie lokal in der Vorschau anzuzeigen:

Zippen Sie den Ordner Cats:
```
cd ..
zip -r Cats.zip Cats
```
Laden Sie die gezippte Datei herunter:
```
download Cats.zip
```
Entzippen Sie die Datei auf Ihrem lokalen Computer, und öffnen Sie index.hml, um die Dateien selbst zu sehen.

Übung: Zusammenarbeit mithilfe eines freigegebenen Repositorys

Erstellen eines Bare-Repositorys

Einrichten für Projektmitarbeiter

Beginn der Zusammenarbeit

Feedback