-
1. Erste Schritte
-
2. Git Grundlagen
-
3. Git Branching
- 3.1 Branches auf einen Blick
- 3.2 Einfaches Branching und Merging
- 3.3 Branch-Management
- 3.4 Branching-Workflows
- 3.5 Remote-Branches
- 3.6 Rebasing
- 3.7 Zusammenfassung
-
4. Git auf dem Server
- 4.1 Die Protokolle
- 4.2 Git auf einem Server einrichten
- 4.3 Erstellung eines SSH-Public-Keys
- 4.4 Einrichten des Servers
- 4.5 Git-Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Von Drittanbietern gehostete Optionen
- 4.10 Zusammenfassung
-
5. Verteiltes Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revisions-Auswahl
- 7.2 Interaktives Stagen
- 7.3 Stashen und Bereinigen
- 7.4 Deine Arbeit signieren
- 7.5 Suchen
- 7.6 Den Verlauf umschreiben
- 7.7 Reset entzaubert
- 7.8 Fortgeschrittenes Merging
- 7.9 Rerere
- 7.10 Debuggen mit Git
- 7.11 Submodule
- 7.12 Bundling
- 7.13 Replace (Ersetzen)
- 7.14 Anmeldeinformationen speichern
- 7.15 Zusammenfassung
-
8. Git einrichten
- 8.1 Git Konfiguration
- 8.2 Git-Attribute
- 8.3 Git Hooks
- 8.4 Beispiel für Git-forcierte Regeln
- 8.5 Zusammenfassung
-
9. Git und andere VCS-Systeme
- 9.1 Git als Client
- 9.2 Migration zu Git
- 9.3 Zusammenfassung
-
10. Git Interna
-
A1. Anhang A: Git in anderen Umgebungen
- A1.1 Grafische Schnittstellen
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Zusammenfassung
-
A2. Anhang B: Git in Ihre Anwendungen einbetten
- A2.1 Die Git-Kommandozeile
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Anhang C: Git Kommandos
- A3.1 Setup und Konfiguration
- A3.2 Projekte importieren und erstellen
- A3.3 Einfache Snapshot-Funktionen
- A3.4 Branching und Merging
- A3.5 Projekte gemeinsam nutzen und aktualisieren
- A3.6 Kontrollieren und Vergleichen
- A3.7 Debugging
- A3.8 Patchen bzw. Fehlerkorrektur
- A3.9 E-mails
- A3.10 Externe Systeme
- A3.11 Administration
- A3.12 Basisbefehle
6.3 GitHub - Ein Projekt betreuen
Ein Projekt betreuen
Nachdem wir nun zu einem Projekt beitragen können, schauen wir uns die andere Seite an: die Erstellung, Wartung und Verwaltung deines eigenen Projekts.
Ein neues Repository erstellen
Erstellen wir ein neues Repository, in dem wir unseren Projekt-Code freigeben können.
Klicke zunächst auf die Schaltfläche „New repository“ auf der rechten Seite des Dashboards oder auf die Schaltfläche +
in der oberen Symbolleiste neben deinem Benutzernamen, wie in Das Dropdown-Menü „New repository“ zu sehen.
Du wirst zum Formular „new repository“ weitergeleitet:
Alles, was du hier wirklich tun musst, ist, einen Projektnamen anzugeben. Die restlichen Felder sind optional.
Fürs Erste klicke einfach auf die Schaltfläche „Create Repository“, und bäm — du verfügst über ein neues Repository auf GitHub mit dem Namen <User>/<Projekt_Name>
.
Da du dort noch keinen Code vorfindest, zeigt dir GitHub Anleitungen an, wie du ein brandneues Git-Repository einrichten oder es zu einem bestehenden Git-Projekt verbinden kannst. Wir werden das hier nicht weiter vertiefen. Wenn du eine Auffrischung benötigst, schaue dir noch einmal Kapitel 2, Git Grundlagen an.
Da dein Projekt jetzt auf GitHub gehostet wird, kannst du die URL an jeden weitergeben, mit dem du dein Projekt teilen möchtest.
Jedes Projekt auf GitHub ist über HTTPS als https://github.com/<User>/<Projekt_Name>
und über SSH als git@github.com:<User>/<Projekt_Name>
erreichbar.
Git kann von diesen beiden URLs abholen/fetchen und auf sie hochladen/pushen. Auf Basis der Anmeldedaten des Benutzers, der sich verbindet, werden die Zugriffsrechte entsprechend beschränkt.
Anmerkung
|
Häufig ist es sinnvoll, die HTTPS-basierte URL für ein öffentliches Projekt zu verwenden, da der Anwender zum Klonen kein GitHub-Konto haben muss. Wenn User per SSH-URL auf dein Projekt zugreifen wollen, müssen sie über ein GitHub-Konto und einen hochgeladenen SSH-Schlüssel verfügen. Die HTTPS-Adresse ist genau die gleiche URL, die du in einen Browser einfügen würdest, um das Projekt dort anzuzeigen. |
Hinzufügen von Mitwirkenden
Wenn du mit anderen Personen zusammenarbeitest, denen du die Erlaubnis zum Committen gewähren möchtest, musst du diese als „collaborators“ (dt. Mitwirkende) eintragen. Ben, Jeff und Louise besitzen ein GitHub-Konto. Wenn du ihnen Push-Zugriff auf dein Repository gewähren möchtest, kannst du sie deinem Projekt hinzufügen. Dadurch erhalten sie „Push“-Zugriff, d.h. sie haben sowohl Lese- als auch Schreibzugriff auf das Projekt und das Git-Repository.
Klicke auf den Link „Settings“ unten rechts in der Seitenleise.
Wähle aus dem Menü auf der linken Seite „Collaborators“. Gib dann einfach einen Benutzernamen in das Feld ein und klicke auf „Add Collaborator“. Du kannst diese Prozedur beliebig oft wiederholen, um so jedem Zugriff zu gewähren. Wenn du die Zugangsberechtigung widerrufen möchtest, klicke einfach auf das "X" auf der rechten Seite der entsprechenden Zeile.
Pull-Requests verwalten
Da es jetzt ein Projekt mit einigem Code und vielleicht sogar ein paar Mitwirkenden gibt, die auch Push-Zugriff haben, lass uns noch einmal darüber nachdenken, was zu tun ist, wenn du einen Pull Request erhältst.
Pull-Requests können entweder von einem Branch in einem Fork deines Repositorys kommen oder von einem anderen Branch im selben Repository. Der einzige Unterschied besteht darin, dass Fork-Pill-Requests oft von Personen stammen, auf deren Branch du nicht pushen kannst und sie nicht auf deinen.Bei internen Pull-Requests haben im Allgemeinen beide Parteien Zugriff auf alle Branches.
Für diese Beispiele nehmen wir an, du bist „tonychacon“ und hast ein neues Arduino-Code-Projekt mit der Bezeichnung „fade“ erstellt.
E-Mail Benachrichtigungen
Irgendjemand bearbeitet deinen Code und sendet dir einen Pull-Request. In diesem Fall solltest du eine E-Mail erhalten, in der du über den neuen Pull-Request informiert wirst. Dieser sollte etwa so aussehen wie in E-Mail Benachrichtigung über einen neuen Pull-Request.
Es gibt ein paar Punkte, die man bei dieser E-Mail beachten sollte. Es gibt ein kleines diffstat – eine Liste von Dateien, die sich im Pull Request geändert haben und um wie sehr sie sich geändert haben. Du erhältst einen Link zum Pull Request auf GitHub. Du erhältst auch ein paar URLs, die du von der Kommandozeile aus verwenden kannst.
Wenn du die Zeile siehst, die git pull <url> patch-1
lautet, ist das eine einfache Möglichkeit, aus einer entfernten Branch zu mergen, ohne einen Remote hinzufügen zu müssen.
Wir haben das in Kapitel 5, Remote-Branches auschecken kurz besprochen.
Wenn du möchtest, kannst du einen Feature-Branch erstellen und in diesen wechseln (engl. checkout). Anschließend kannst du diesen Befehl ausführen, um die Änderungen in dem Pull-Request zu mergen.
Die anderen interessanten URLs sind die .diff
und .patch
URLs, die, wie du vielleicht vermutest, vereinheitlichte Diff- und Patch-Versionen des Pull Requests bereitstellen.
Technisch gesehen kannst du die Arbeit im Pull-Request mit einem Befehl wie diesem zusammenführen:
$ curl https://github.com/tonychacon/fade/pull/1.patch | git am
Mitwirkung beim Pull Request
Wie in Github Workflow beschrieben, kannst du nun eine Diskussion mit der Person führen, die den Pull Request geöffnet hat. Du kannst bestimmte Code-Zeilen kommentieren, ganze Commits kommentieren oder den gesamten Pull-Request selbst kommentieren, indem du „GitHub Flavored Markdown“ an beliebiger Stelle verwendest.
Jedes Mal, wenn jemand den Pull-Request kommentiert, erhältst du weitere E-Mail-Benachrichtigungen, damit du weißt, dass Aktivitäten stattfinden. Du wirst jeweils einen Link zum Pull Request erhalten, in dem die Aktivität stattfindet. Auf die E-Mails kannst du auch direkt antworten, um den Pull-Request-Thread zu kommentieren.
Sobald der Quellcode soweit korrekt ist und du ihn zusammenführen möchtest, kannst du ihn mit der Anweisung git pull <url> <branch>
(wie zuvor gesehen) pullen und lokal mergen. Oder du fügst den Fork als Remote hinzu, fetchst den Patch und mergst ihn anschließend.
Wenn das Zusammenführen trivial ist, kannst du auch einfach auf der GitHub-Seite auf die Schaltfläche „Merge“ klicken. Dadurch wird ein „non-fast-forward“ Merge durchgeführt, wodurch ein Merge-Commit erstellt wird, auch wenn ein „fast-forward“ Merge möglich gewesen wäre. Das bedeutet, dass unabhängig davon, was du tust, jedes Mal, wenn du auf die Schaltfläche Merge klickst, ein Merge-Commit erstellt wird. Wie du in Merge-Button und Anweisungen zum manuellen Zusammenführen eines Pull-Requests sehen kannst, gibt dir GitHub all diese Informationen, wenn du auf den Hinweis-Link klickst.
Wenn du dich entscheidest, dass du ihn nicht zusammenführen möchtest, kannst du auch einfach den Pull-Request schließen und die Person, die ihn geöffnet hat, wird benachrichtigt.
Pull Request Refs (Referenzen)
Wenn du m< viele Pull-Requests erhältst und nicht jedes Mal einen ganzen Batzen Remotes hinzufügen oder einmalige Pulls durchführen willst, gibt es einen tollen Kniff in GitHub. Es handelt sich um einen fortgeschrittenen Trick, den wir in Kapitel 10, Refspecs ausführlicher durchgehen werden. Er kann jedoch recht nützlich sein.
GitHub beschreibt die Pull-Request-Branches für ein Repository als eine Art Pseudo-Branch auf dem Server. Normalerweise werden sie beim Klonen nicht angezeigt- Sie sind jedoch verdeckt vorhanden und man kann recht einfach darauf zugreifen.
Um das zu verdeutlichen, werden wir den Low-Level-Befehl ls-remote
verwenden, der oft als Git-Basisbefehl (engl. plumbing) bezeichnet wird und über den wir in Basisbefehle und Standardbefehle (Plumbing and Porcelain) mehr lesen werden.
Dieses Kommando wird im Regelfall nicht im täglichen Gebrauch von Git verwendet, aber es ist zweckmäßig, um uns zu zeigen, welche Referenzen auf dem Server vorhanden sind.
Wenn wir diesen Befehl gegen das „blink“ Repository ausführen, das wir vorhin benutzt haben, erhalten wir eine Liste aller Branches und Tags, sowie anderer Referenzen im Repository.
$ git ls-remote https://github.com/schacon/blink
10d539600d86723087810ec636870a504f4fee4d HEAD
10d539600d86723087810ec636870a504f4fee4d refs/heads/master
6a83107c62950be9453aac297bb0193fd743cd6e refs/pull/1/head
afe83c2d1a70674c9505cc1d8b7d380d5e076ed3 refs/pull/1/merge
3c8d735ee16296c242be7a9742ebfbc2665adec1 refs/pull/2/head
15c9f4f80973a2758462ab2066b6ad9fe8dcf03d refs/pull/2/merge
a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head
31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/merge
Wenn du dich in deinem Repository befindest und git ls-remote origin
ausführst (oder auch einen beliebigen anderen Remote, den du überprüfen möchtest), dann sieht die Ausgabe ähnlich aus.
Wenn sich das Repository auf GitHub befindet und es offnee Pull-Requests gibt, werden diese Referenzen mit vorangestelltem refs/pull/
angezeigt.
Das sind im Prinzip Branches, die aber nicht unter refs/heads/
stehen. Sie werden normalerweise nicht angezeigt, wenn du klonst oder vom Server fetchst – der Fetching-Prozess ignoriert sie normalerweise.
Es gibt zwei Referenzen pro Pull-Request – eine endet mit /head
. Sie zeigt auf genau den gleichen Commit wie der letzte Commit im Pull-Request-Branch.
Wenn also jemand einen Pull-Request in unserem Repository öffnet und sein Branch bug-fix
heißt, der auf a5a775
zeigt, dann haben wir in unserem Repository keinen bug-fix
Branch (weil der in seinem Fork liegt). Wir haben jedoch pull/<pr#>/head
, der auf a5a775
zeigt.
Das heißt, wir können jeden Pull-Request-Branch herunterladen, ohne lokal einen Menge Remotes hinzufügen zu müssen.
Jetzt kannst du das Fetchen dieser Referenz direkt durchführen.
$ git fetch origin refs/pull/958/head
From https://github.com/libgit2/libgit2
* branch refs/pull/958/head -> FETCH_HEAD
Damit sagt man Git: „Verbinde dich mit dem origin
Remote und laden die Referenz refs/pull/958/head
herunter.“
Git macht das mit Vergnügen und lädt alles herunter, was du brauchst, um diesen Ref zu erstellen. Es setzt einen Zeiger auf den Commit, den du unter .git/FETCH_HEAD
haben willst.
Du kannst die Bearbeitung mit git merge FETCH_HEAD
in einen Branch fortsetzen. In diesem könntest du die Änderung testen. Die Merge-Commit-Nachricht sieht jedoch ein wenig merkwürdig aus.
Wenn du viele Pull-Requests überprüfen musst, wird das etwas umständlich.
Es gibt auch eine Möglichkeit wie du alle Pull-Requests abrufen und aktuell halten kannst, wann immer du dich mit dem Remote verbindest.
Öffne .git/config
in deinem bevorzugten Editor und suche nach dem origin
Remote.
Es sollte etwa so aussehen:
[remote "origin"]
url = https://github.com/libgit2/libgit2
fetch = +refs/heads/*:refs/remotes/origin/*
Die Zeile, die mit fetch =
beginnt, ist eine „refspec.“
Es ist eine Möglichkeit, Namen auf dem Remote auf Namen in deinem lokalen .git
Verzeichnis zuzuordnen.
Dieser hier sagt git: „die Sachen auf dem Remote, die unter refs/heads
liegen, sollten in meinem lokalen Repository unter refs/remotes/origin
abgelegt werden.“
Du kannst diesen Teil ändern, um eine weitere Referenz (refspec) hinzuzufügen:
[remote "origin"]
url = https://github.com/libgit2/libgit2.git
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
Diese letzte Zeile sagt Git: „Alle Referenzen, die wie refs/pull/123/head
aussehen, sollten lokal als refs/remotes/origin/pr/123
gespeichert werden.“
Wenn du diese Änderung speicherst und ein git fetch
ausführst, passiert folgendes:
$ git fetch
# …
* [new ref] refs/pull/1/head -> origin/pr/1
* [new ref] refs/pull/2/head -> origin/pr/2
* [new ref] refs/pull/4/head -> origin/pr/4
# …
Nun werden alle Remote-Pull-Requests lokal mit Referenzen (refs) abgebildet, die sich ähnlich wie das Tracken von Branches verhalten. Sie sind schreibgeschützt und werden aktualisiert, wenn du ein Fetch durchführst. Dadurch ist es besonders einfach, den Code aus einer Pull-Anforderung lokal auszuprobieren:
$ git checkout pr/2
Checking out files: 100% (3769/3769), done.
Branch pr/2 set up to track remote branch pr/2 from origin.
Switched to a new branch 'pr/2'
Diejenigen mit Adleraugen unter euch werden das head
am Ende des Remote-Abschnitts der refspec bemerkt haben.
Es gibt auch ein refs/pull/#/merge
ref auf der GitHub-Seite, der den Commit darstellt, der sich ergeben würde, wenn du auf die Schaltfläche „merge“ klickst.
Auf diese Weise kannst du das Ergebnis des Pull-Requests testen, bevor du überhaupt auf die Schaltfläche geklickt hast.
Pull-Requests auf Pull-Requests
Du kannst nicht nur Pull-Requests öffnen, die auf den Haupt- oder master
Branch zeigen. Du kannst Pull-Request, gegen jeden beliebigen Branch im Netzwerk stellen.
Du kannst sogar einen anderen Pull-Request als Ziel wählen.
Wenn du einen Pull-Request siehst, der dir gefällt und du eine Idee für eine Änderung hast, die von ihm abhängt; oder du dir nicht sicher bist, ob dieser Pull-Request überhaupt eine gute Idee ist; oder du keine Push-Berechtigung zum Zie-Branch hast – kannst du einen Pull-Request auf diesen anderen Pull-Request öffnen.
Wenn du einen Pull-Request öffnest, befindet sich oben auf der Seite ein Feld, das angibt, von welchem Branch du pullen und in welchen du den Pull-Vorgang ausführen möchtest. Wenn du auf die Schaltfläche „Edit“ (Bearbeiten), rechts neben diesem Feld, klickst, kannst du nicht nur die Branches, sondern auch den Fork ändern.
Hier kannst du relativ einfach angeben, ob dein neuer Branch in einen anderen Pull-Request oder in einen anderen Fork des Projekts zusammengeführt werden soll.
Erwähnen und Benachrichtigen
GitHub hat auch ein ziemlich praktisches Benachrichtigungssystem integriert, das bei Fragen oder Rückmeldungen von einzelnen Personen oder Teams eine große Hilfe sein kann.
In jedem Kommentar kannst du mit der Eingabe eines @
-Zeichens beginnen und es wird automatisch mit den Namen und Benutzernamen von Personen vervollständigt, die Mitstreiter oder Beitragende des Projektes sind.
Du kannst auch einen Benutzer angeben, der sich nicht in diesem Dropdown-Menü befindet, aber oft ist der Auto-Komplettierer schneller.
Sobald du einen Kommentar mit einer Benutzererwähnung postest, wird dieser Benutzer benachrichtigt. Damit ist es möglich, Andere effektiv in Gespräche einbinden, anstatt sie einfach nur zu befragen. Häufig werden bei Pull-Requests auf GitHub andere Personen in Teams oder Unternehmen einbezogen, um ein Issue oder Pull-Requests zu überprüfen.
Wenn jemand in einem Pull-Request oder Issue erwähnt wird, wird er darauf „abonniert“ (engl. subscribed) und erhält immer dann weitere Benachrichtigungen, wenn eine Aktivität dort stattfindet. Du wirst auch subskribiert, wenn der Pull-Request von dir geöffnet wurde, wenn du das Repository beobachten oder wenn du etwas kommentierst. Wenn du keine weiteren Benachrichtigungen mehr erhalten möchtest, kannst du auf die Schaltfläche “Unsubscribe” klicken, um dich von den Benachrichtigungen abzumelden.
Die Benachrichtigungs-Seite
Wenn wir hier „Benachrichtigungen“ (engl. notifications) erwähnen, meinen wir wie GitHub versucht dich zu informieren, falls ein Ereignis eintritt. Es gibt ein paar Einstellungen, die du konfigurieren kannst. Wenn du von der Settings-Seite aus auf die Registerkarte "Notifications" gehst, siehst du einige der verfügbaren Optionen.
Die beiden Möglichkeiten sind: über „E-Mail“ oder „Web“ benachrichtigen. Du kannst entweder eine, keine oder beide Optionen wählen, wenn du dich an den Aktivitäten in Repositorys beteiligst, die du gerade beobachtest.
Web Benachrichtigungen
Web-Benachrichtigungen landen nur auf GitHub und du kannst sie nur auf GitHub überprüfen. Wenn du diese Option in deinen Einstellungen ausgewählt hast und eine Benachrichtigung für dich ausgelöst wird, siehst du oben auf deinem Bildschirm einen kleinen blauen Punkt über deinem Benachrichtigungssymbol, wie in Benachrichtigungen zu sehen ist.
Wenn du darauf klickst, siehst du eine Liste aller Elemente, über die du informiert wurdest, gruppiert nach Projekten. Du kannst nach den Benachrichtigungen eines bestimmten Projekts filtern, indem du auf dessen Namen in der linken Seitenleiste klickst. Du kannst deine Benachrichtigung als Gelesen markieren indem du das Häkchens neben einer Meldung anklickst oder alle Benachrichtigungen in einem Projekt bestätigen indem du das Häkchens oben in der Gruppe anklickst. Es gibt auch eine Mute-Taste neben jedem Häkchen, die du anklicken kannst, um keine weiteren Mitteilungen zu diesem Thema zu erhalten.
Diese Tools sind alle sehr praktisch für die Organisation vieler Benachrichtigungen in GitHub. Viele GitHub Power-User schalten E-Mail-Benachrichtigungen einfach komplett aus und verwalten ihre gesamten Benachrichtigungen über die Web-Oberfläche.
E-Mail Benachrichtigungen
E-Mail-Benachrichtigungen sind die zweite Variante, mit der du Benachrichtigungen über GitHub erhalten kannst. Wenn du diese Option aktiviert hast, erhältst du E-Mails für jede Mitteilung. Wir haben Beispiele dafür in E-Mail Benachrichtigungen und E-Mail Benachrichtigung über einen neuen Pull-Request gesehen. Die E-Mails werden auch nach Thema sortiert, was sehr hilfreich ist, wenn dein E-Mail-Client entsprechend konfiguriert ist.
In den Headern der E-Mails, die GitHub dir sendet, sind auch eine ganze Reihe von Metadaten eingebettet, was bei der Einrichtung angepasster Filter und Regeln sehr nützlich sein kann.
Wenn wir uns zum Beispiel die aktuellen E-Mail-Header ansehen, der in E-Mail Benachrichtigung über einen neuen Pull-Request angezeigten E-Mail, die an Tony gesendet wurde, werden wir unter den gesendeten Informationen Folgendes sehen:
To: tonychacon/fade <fade@noreply.github.com>
Message-ID: <tonychacon/fade/pull/1@github.com>
Subject: [fade] Wait longer to see the dimming effect better (#1)
X-GitHub-Recipient: tonychacon
List-ID: tonychacon/fade <fade.tonychacon.github.com>
List-Archive: https://github.com/tonychacon/fade
List-Post: <mailto:reply+i-4XXX@reply.github.com>
List-Unsubscribe: <mailto:unsub+i-XXX@reply.github.com>,...
X-GitHub-Recipient-Address: tchacon@example.com
Es gibt hier noch ein paar interessante Kleinigkeiten.
Möchtest du E-Mails zu einem Projekt oder Pull Request hervorheben oder umleiten, erhältst du alle notwendige Daten in Message-ID
im <user>/<project>/<type>/<id>
Format.
Wenn das, zum Beispiel, ein Issue wäre, dann wäre das Feld <type>
eher „Issues“ als „Pull“ gewesen.
Die List-Post
und List-Unsubscribe
Felder bedeuten, dass du, wenn du einen Mail-Client haben, der das versteht, ganz einfach in die Liste posten oder dich vom Thread „abmelden“ (engl. unsubscribe) kannst.
Das wäre im Wesentlichen dasselbe wie das Anklicken des „Mute“ Buttons in Web-Benachrichtigungen oder „Unsubscribe“ auf der Issue- oder Pull-Request-Seite selbst.
Es ist auch wichtig zu wissen, dass, wenn du sowohl E-Mail- als auch Web-Benachrichtigungen aktiviert hast und du die E-Mail-Version der Benachrichtigung liest, die Web-Version auch als gelesen markiert wird, falls du in deinem Mail-Client Bilder erlaubt hast.
Besondere Dateien
Es gibt ein paar besondere Dateien, die GitHub erkennt, wenn sie in deinem Repository vorhanden sind.
README
Zuerst ist da die README
Datei, die in nahezu jedem Dateiformat vorliegen kann, das GitHub als Text erkennt.
Zum Beispiel könnte es sich um README
, README.md
, README.asciidoc
usw. handeln.
Wenn GitHub eine README-Datei in deinem Projekt findet, wird sie auf der Startseite des Projekts angezeigt.
Viele Teams verwenden diese Datei, um alle relevanten Projektinformationen für Personen zu sammeln, die neu im Repository oder Projekt sind. Dazu gehören in der Regel Sachen wie:
-
Wofür ist das Projekt vorgesehen
-
Wie wird es konfiguriert und installiert
-
Ein Beispiel, wie man es anwendet oder zum Laufen bringt
-
Die Lizenz, unter der das Projekt zur Verfügung steht
-
Wie man dazu beitragen kann
Da GitHub diese Datei rendert, kannst du Bilder oder Links in sie einbetten, um sie besser verständlich zu machen.
CONTRIBUTING
Die andere von GitHub erkannte, spezielle Datei ist die Datei CONTRIBUTING
.
Wenn du eine CONTRIBUTING
Datei mit einer beliebigen Dateiendung verwendest, zeigt GitHub sie wie in Einen Pull-Request starten, wenn eine CONTRIBUTING-Datei existiert gezeigt an, wenn irgend jemand einen Pull-Request öffnet.
Die Absicht dabei ist, dass du bestimmte Punkte spezifizieren kannst, die du benötigst oder nicht wünschst, für Pull-Requests, die an deinem Projekt gesendet werden. Auf diese Weise kann ein Benutzer die Leitlinien auch wirklich lesen, bevor er den Pull-Request eröffnet.
Projekt-Administration
Generell gibt es nur wenige administrative Aufgaben, die du mit einem einzelnen Projekt durchführen kannst, aber ein paar Punkte könnten interessant sein.
Ändern des Standard-Branchs
Wenn du einen anderen Branch als „master“ als Standard-Branch verwenden willst, auf den die Teilnehmer Pull-Requests öffnen oder ihn standardmäßig sehen sollen, dann kannst du das auf der Settings-Seite deines Repositorys unter der Registerkarte „Optionen“ ändern.
Ändere einfach den Standard-Branch in der Dropdown-Liste und das ist dann der Vorgabewert für alle wichtigen Operationen, einschließlich des Branchs, der standardmäßig ausgecheckt wird, wenn jemand das Repository klont.
Übertragen eines Projektes
Wenn du ein Projekt auf einen anderen Benutzer oder eine Organisation in GitHub übertragen möchtest, gibt es unten auf der gleichen Registerkarte „Optionen“ deiner Repository-Einstellungen eine Option „Eigentum übertragen“ (engl. Transfer ownership), die das ermöglicht.
Diese Option ist sinnvoll, wenn du ein Projekt aufgibst und es von jemandem übernommen werden soll oder wenn dein Projekt größer wird und du es in eine andere Organisation verlagern möchtest.
Dadurch wird nicht nur das Repository zusammen mit all seinen Beobachtern und Sternen an einen anderen Ort verschoben, sondern es wird auch ein Redirect von deiner URL an den neuen Ort eingerichtet. Es wird auch die Klone und Fetches von Git umleiten, nicht nur die Web-Anfragen.