Git
Chapters ▾ 2nd Edition

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 Ihres eigenen Projekts.

Ein neues Repository erstellen

Erstellen wir ein neues Repository, in dem wir unseren Projekt-Code freigeben können. Klicken Sie zunächst auf die Schaltfläche „New repository“ auf der rechten Seite des Dashboards oder auf die Schaltfläche + in der oberen Symbolleiste neben Ihrem Benutzernamen, wie in Das Dropdown-Menü „New repository“ zu sehen.

Der Bereich „Your repositories“
Figure 109. Der Bereich „Your repositories“
Das Dropdown-Menü „New repository“
Figure 110. Das Dropdown-Menü „New repository“

Sie werden zum Formular „new repository“ weitergeleitet:

Das Formular „new repository“
Figure 111. Das Formular „new repository“

Alles, was Sie hier wirklich tun müssen, ist, einen Projektnamen anzugeben; die restlichen Felder sind völlig optional. Fürs Erste klicken Sie einfach auf die Schaltfläche „Create Repository“, und boom – Sie verfügen über ein neues Repository auf GitHub mit dem Namen <User>/<Projekt_Name>.

Da Sie dort noch keinen Code vorfinden, zeigt Ihnen GitHub Anleitungen an, wie Sie ein brandneues Git-Repository einrichten oder zu einem bestehenden Git-Projekt verbinden können. Wir werden das hier nicht weiter vertiefen; wenn Sie eine Auffrischung benötigen, schauen Sie sich noch einmal Kapitel 2, Git Grundlagen an.

Da Ihr Projekt jetzt auf GitHub gehostet wird, können Sie die URL an jeden weitergeben, mit dem Sie Ihr Projekt teilen möchten. 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 mit ihnen verbindet, werden die Zugriffsrechte entsprechend beschränkt.

Note

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 Ihr 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 sie in einen Browser einfügen würden, um das Projekt dort anzuzeigen.

Hinzufügen von Mitwirkenden

Wenn Sie mit anderen Personen zusammenarbeiten, denen Sie die Erlaubnis zum Committen gewähren möchten, müssen Sie diese als „collaborators“ (dt. Mitwirkende) eintragen. Ben, Jeff und Louise, Benutzer von GitHub-Konten, denen Sie Push-Zugriff auf Ihr Repository gewähren möchten, können Sie so zu Ihrem Projekt hinzufügen. Dadurch erhalten sie „Push“-Zugriff, d.h. sie haben sowohl Lese- als auch Schreibzugriff auf das Projekt und das Git-Repository.

Klicken Sie auf den Link „Settings“ unten rechts in der Sidebar.

Der Settings-Link des Repositorys
Figure 112. Der Settings-Link des Repositorys

Wählen Sie dann aus dem Menü auf der linken Seite „Collaborators“. Geben Sie dann einfach einen Benutzernamen in das Feld ein und klicken Sie auf „Add Collaborator“. Sie können diese Prozedur beliebig oft wiederholen, um so jedem, den Sie möchten, Zugriff zu gewähren. Wenn Sie die Zugangsberechtigung widerrufen möchten, klicken Sie einfach auf das "X" auf der rechten Seite der entsprechenden Zeile.

Liste der Repository-Mitwirkenden
Figure 113. Mitwirkende im Repository

Pull-Requests handhaben

Da es jetzt ein Projekt mit einigem Code und vielleicht sogar ein paar Mitwirkenden gibt, die auch Push-Zugriff haben, lassen Sie uns noch einmal darüber nachdenken, was zu tun ist, wenn Sie selbst einen Pull Request erhalten.

Pull-Requests können entweder von einem Branch in einem Fork Ihres Repositories kommen oder von einem anderen Branch im selben Repository. Der einzige Unterschied besteht darin, dass die von einer Fork oft von Personen stammen, die nicht zu ihrem Branch gepusht werden können und sie nicht zu deren, während bei internen Pull-Requests im Allgemeinen beide Parteien Zugriff auf den Branch haben.

Für diese Beispiele nehmen wir an, Sie sind „tonychacon“ und haben ein neues Arduino-Code-Projekt mit der Bezeichnung „fade“ erstellt.

E-Mail Benachrichtigungen

Jemand meldet sich bei Ihnen, bearbeitet Ihren Code und sendet Ihnen einen Pull-Request. In diesem Fall sollten Sie eine E-Mail erhalten, in der Sie über den neuen Pull-Request informiert werden und dieser sollte etwa so aussehen wie in E-Mail Benachrichtigung über einen neuen Pull-Request.

Pull-Request
Figure 114. 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 wieviel. Sie erhalten einen Link zum Pull Request auf GitHub. Sie enthält auch ein paar URLs, die Sie von der Kommandozeile aus verwenden können.

Wenn Sie die Zeile sehen, 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 Sie möchten, können Sie einen Themen-Branch erstellen und in diesen wechseln (engl. checkout) und dann 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 Sie vielleicht vermuten, vereinheitlichte Diff- und Patch-Versionen des Pull Requests bereitstellen. Technisch gesehen könnten Sie 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, können Sie nun eine Diskussion mit der Person führen, die den Pull Request geöffnet hat. Sie können bestimmte Code-Zeilen kommentieren, ganze Commits kommentieren oder den gesamten Pull-Request selbst kommentieren, indem Sie „GitHub Flavored Markdown“ an beliebiger Stelle verwenden.

Jedes Mal, wenn jemand den Pull-Request kommentiert, erhalten Sie weitere E-Mail-Benachrichtigungen, damit Sie wissen, dass Aktivitäten stattfinden. Sie werden jeweils einen Link zum Pull Request enthalten, in dem die Aktivität stattfindet. Auf die E-Mails können Sie auch direkt antworten, um den Pull-Request-Thread zu kommentieren.

E-Mail Antwort
Figure 115. Antworten auf E-Mails sind in den Thread integriert

Sobald der Quellcode richtig platziert ist und Sie ihn zusammenführen möchten, können Sie ihn mit der Anweisung git pull <url> <branch> (wie zuvor gesehen) pullen und lokal mergen oder Sie fügen den Fork als Remote hinzu, fetchen den Patch und mergen ihn anschließend.

Wenn das Zusammenführen trivial ist, können Sie 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 Sie tun, jedes Mal, wenn Sie auf die Schaltfläche Merge klicken, ein Merge-Commit erstellt wird. Wie Sie in Merge-Button und Anweisungen zum manuellen Zusammenführen eines Pull-Requests sehen können, gibt Ihnen GitHub all diese Informationen, wenn Sie auf den Hinweis-Link klicken.

Merge-Button
Figure 116. Merge-Button und Anweisungen zum manuellen Zusammenführen eines Pull-Requests

Wenn Sie sich entscheiden, dass Sie ihn nicht zusammenführen möchten, können Sie auch einfach den Pull-Request schließen und die Person, die ihn geöffnet hat, wird benachrichtigt.

Pull Request Refs (Referenzen)

Wenn Sie mit vielen Pull-Requests zu kämpfen haben und nicht jedes Mal einen ganzen Batzen Remotes hinzufügen oder einmalige Pulls durchführen wollen, gibt es einen tollen Kniff, den GitHub Ihnen anbietet. Es handelt sich um einen fortgeschrittenen Kunstgriff, den wir in Kapitel 10, Refspecs ausführlicher durchgehen werden. Er kann jedoch recht nützlich sein.

GitHub preist die Pull-Request-Branches für ein Repository als eine Art Pseudo-Zweig auf dem Server an. Normalerweise werden sie beim Klonen nicht angezeigt, aber sie sind verdeckt vorhanden und man kann ziemlich leicht darauf zugreifen.

Um das zu verdeutlichen, werden wir den Low-Level-Befehl ls-remote verwenden, der oft als „plumbing“ Befehl 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 Sie sich in Ihrem Repository befinden und git ls-remote origin ausführen (oder auch einen beliebigen anderen Remote, den Sie überprüfen möchten), dann wird Ihnen das etwas Vergleichbares angezeigt.

Wenn sich das Repository auf GitHub befindet und Sie irgendwelche geöffnete Pull-Requests haben, 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 Sie klonen oder vom Server fetchen – 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 in der 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 Zweig (weil der in seinem Fork liegt). Aber wir werden pull/<pr#>/head bekommen, der auf a5a775 zeigt. Das heißt, wir können ziemlich einfach jeden Pull-Request-Branch in einem Rutsch herunterladen, ohne einen Stapel Remotes hinzufügen zu müssen.

Jetzt könnten Sie das Fetchen der Referenz direkt durchführen.

$ git fetch origin refs/pull/958/head
From https://github.com/libgit2/libgit2
 * branch            refs/pull/958/head -> FETCH_HEAD

Git erhält die Meldung: „Verbinden Sie sich mit dem origin-Remote und laden Sie die Referenz refs/pull/958/head herunter.“ Git folgt gern und lädt alles herunter, was Sie brauchen, um diesen Ref zu erstellen. Es setzt einen Zeiger auf den Commit, den Sie unter .git/FETCH_HEAD haben wollen. Sie können das mit git merge FETCH_HEAD in einen Branch fortsetzen. In diesem wollen Sie testen, aber die Merge-Commit-Nachricht sieht ein wenig merkwürdig aus. Wenn Sie viele Pull-Requests überprüfen müssen, wird das umständlich.

Es gibt auch eine Möglichkeit wie Sie alle Pull-Requests abrufen und aktuell zu halten können, wann immer Sie sich mit dem Remote verbinden. Öffnen Sie .git/config in Ihrem bevorzugten Editor und suchen Sie nach dem origin Remote. Es sollte ein bißchen wie folgt 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 den Namen in Ihrem lokalen .git-Verzeichnis zuzuordnen. Das sagt Git speziell: „die Sachen auf dem Remote, die unter refs/heads liegen, sollten in meinem lokalen Repository unter refs/remotes/origin abgelegt werden.“ Sie können 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 meldet Git: „Alle Referenzen, die wie refs/pull/123/head aussehen, sollten lokal als refs/remotes/origin/pr/123 gespeichert werden.“ Wenn Sie jetzt diese Datei speichern und ein git fetch auslösen, 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 Sie einen Fetch durchführen. 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 unter Ihnen mit Adleraugen werden das head am Ende des Remote-Abschnitts der refspec bemerken. Es gibt auch ein refs/pull/#/merge ref auf der GitHub-Seite, der den Commit darstellt, der sich ergeben würde, wenn Sie auf die Schaltfläche „merge“ klicken. Dies kann es Ihnen ermöglichen, das Zusammenführen zu testen, bevor Sie überhaupt auf die Schaltfläche klicken. Auf diese Weise können Sie das Mergen testen, bevor Sie überhaupt auf die Schaltfläche klicken.

Pull-Requests auf Pull-Requests

Sie können nicht nur Pull-Requests öffnen, die auf den Haupt- oder master-Branch gerichtet sind, sondern auch einen Pull-Request, der auf einen beliebigen Branch im Netzwerk ausgerichtet ist. Vielmehr können Sie sogar einen weiteren Pull-Request als Ziel wählen.

Wenn Sie einen Pull-Request sehen, der sich in die richtige Richtung bewegt und Sie eine Idee für eine Änderung haben, die von ihm abhängt; oder Sie sich nicht sicher sind, ob er eine gute Idee ist; oder Sie einfach keinen Push-Zugang zum Zielbranch haben – dann können Sie einen Pull-Request auf diesen direkt öffnen.

Wenn Sie einen Pull-Request öffnen, befindet sich oben auf der Seite ein Feld, das angibt, von welchem Branch Sie pullen und in welchen Sie den Pull-Vorgang ausführen möchten. Wenn Sie auf die Schaltfläche „Edit“ (Bearbeiten), rechts neben diesem Feld, klicken, können Sie nicht nur die Branches, sondern auch den Fork ändern.

PR Ziele
Figure 117. Manuelles Ändern der Pull-Request Ziel-Fork und der Branch

Hier können Sie relativ einfach angeben, ob Ihr neuer Branch in einen anderen Pull-Request oder einen anderen Fork des Projekts zusammengeführt werden soll.

Nennen und Benachrichtigen

GitHub hat auch ein ziemlich praktisches Benachrichtigungssystem integriert, das bei Fragen oder Rückmeldungen von einzelnen Personen oder Teams eine Hilfe sein kann.

In jedem Kommentar können Sie mit der Eingabe eines @-Zeichens beginnen und es wird automatisch mit den Namen und Benutzernamen von Personen vervollständigt, die Mitarbeiter oder Beitragende für das Projekt sind.

Nennungen
Figure 118. Mit der Eingabe von @ anfangen, um jemanden zu nennen.

Sie können auch einen Benutzer angeben, der sich nicht in diesem Dropdown-Menü befindet, aber oft ist der Auto-Komplettierer schneller.

Sobald Sie einen Kommentar mit einer Benutzererwähnung posten, wird dieser Benutzer benachrichtigt. Damit ist es möglich, Menschen wirklich effektiv in Gespräche zu verwickeln, anstatt sie zur Teilnahme zu drängen. 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. Sie werden auch subskribiert, wenn er von Ihnen geöffnet wurde, wenn Sie das Repository beobachten oder wenn Sie etwas kommentieren. Wenn Sie keine weiteren Benachrichtigungen mehr erhalten möchten, können Sie auf die Schaltfläche “Unsubscribe” klicken, um sich von den Benachrichtigungen abzumelden.

Unsubscribe
Figure 119. Von einer Issue- oder Pull-Request-Benachrichtigung abmelden

Die Benachrichtigungs-Seite

Wenn wir hier „Benachrichtigungen“ (engl. notifications) erwähnen, meinen wir wie GitHub versucht Sie zu erreichen, falls ein Ereigniss eintritt. Es gibt ein paar Einstellungen, die Sie konfigurieren können. Wenn Sie von der Settings-Seite aus auf die Registerkarte "Notifications" gehen, sehen Sie einige der verfügbaren Optionen.

Notification center
Figure 120. Benachrichtigungs-Optionen

Die beiden Möglichkeiten sind: über „E-Mail“ oder „Web“ benachrichtigen. Sie können entweder eine, keine oder beide Optionen wählen, wenn Sie sich an den Aktivitäten in Repositorien beteiligen, die Sie gerade beobachten.

Web Benachrichtigungen

Web-Benachrichtigungen gibt es nur auf GitHub und Sie können sie nur auf GitHub überprüfen. Wenn Sie diese Option in Ihren Einstellungen ausgewählt haben und eine Benachrichtigung für Sie ausgelöst wird, sehen Sie oben auf Ihrem Bildschirm einen kleinen blauen Punkt über Ihrem Benachrichtigungssymbol, wie in Benachrichtigungen zu sehen ist.

Benachrichtigungen
Figure 121. Benachrichtigungen

Wenn Sie darauf klicken, sehen Sie eine Liste aller Elemente, über die Sie informiert wurden, gruppiert nach Projekten. Sie können nach den Benachrichtigungen eines bestimmten Projekts filtern, indem Sie auf dessen Namen in der linken Seitenleiste klicken. Möglich ist auch die Übernahme der Benachrichtigung durch Anklicken des Häkchens neben einer Meldung oder die Übernahme aller Benachrichtigungen in einem Projekt durch Anklicken des Häkchens oben in der Gruppe. Es gibt auch eine Mute-Taste neben jedem Häkchen, die Sie anklicken können, um keine weiteren Mitteilungen zu diesem Thema zu erhalten.

Diese Tools sind alle sehr praktisch für die Bearbeitung einer großen Anzahl von Benachrichtigungen. Viele GitHub Power-User schalten E-Mail-Benachrichtigungen einfach komplett aus und verwalten ihre gesamten Benachrichtigungen über diese Seite.

E-Mail Benachrichtigungen

E-Mail-Benachrichtigungen sind die zweite Variante, mit der Sie Benachrichtigungen über GitHub auswerten können. Wenn Sie diese Option aktiviert haben, erhalten Sie 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 richtig nach Thema sortiert, was sehr hilfreich ist, wenn Ihr E-Mail-Client entsprechend konfiguriet ist.

In den Headern der E-Mails, die GitHub Ihnen 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 zwischen 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öchten Sie E-Mails zu diesem speziellen Projekt oder sogar Pull Request hervorheben oder umleiten, erhalten Sie mit den Informationen in Message-ID alle Daten 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 Sie, wenn Sie einen Mail-Client haben, der das versteht, ganz einfach in die Liste posten oder sich vom Thread „abmelden“ (engl. unsubscribe) können. 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 Sie sowohl E-Mail- als auch Web-Benachrichtigungen aktiviert haben und Sie die E-Mail-Version der Benachrichtigung lesen, die Web-Version auch als gelesen markiert wird, falls Sie in Ihrem Mail-Client Bilder erlaubt haben.

Besondere Dateien

Es gibt ein paar besondere Dateien, die GitHub erkennt, wenn sie in Ihrem 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 Ihrem Quellcode 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, können Sie 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 Sie eine CONTRIBUTING Datei mit einer beliebigen Dateiendung verwenden, zeigt GitHub wie in Einen Pull-Request starten, wenn eine CONTRIBUTING-Datei existiert an, wenn irgend jemand einen Pull-Request öffnet.

Contributing Notiz
Figure 122. Einen Pull-Request starten, wenn eine CONTRIBUTING-Datei existiert

Die Absicht dabei ist, dass Sie bestimmte Punkte spezifizieren können, die Sie benötigen oder nicht wünschen, für Pull-Requests, die an Ihr Projekt gesendet werden. Auf diese Weise kann ein Benutzer die Leitlinien auch wirklich lesen, bevor er den Pull-Request öffnet.

Projekt-Administration

Generell gibt es nur wenige administrative Aufgaben, die Sie mit einem einzelnen Projekt durchführen können, aber ein paar Punkte könnten interessant sein.

Ändern der Standard-Branch

Wenn Sie einen anderen Branch statt „master“ als Standard-Zweig verwenden wollen, auf den die Teilnehmer Pull-Requests öffnen oder ihn standardmäßig sehen sollen, dann können Sie das auf der Settings-Seite Ihres Repositorys unter der Registerkarte „Optionen“ ändern.

Default branch
Figure 123. Change the default branch for a project.

Ändern Sie 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 Sie ein Projekt auf einen anderen Benutzer oder eine Organisation in GitHub übertragen möchten, gibt es unten auf der gleichen Registerkarte „Optionen“ Ihrer Repository-Einstellungen eine Option „Eigentum übertragen“ (engl. Transfer ownership), die das ermöglicht.

Transfer
Figure 124. Übertragen eines Projekts auf einen anderen GitHub-User oder eine andere Organisation

Diese Option ist sinnvoll, wenn Sie ein Projekt aufgeben und es von jemandem übernommen werden soll oder wenn Ihr Projekt größer wird und Sie es in eine Organisation verlagern möchten.

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 Ihrer URL an den neuen Ort eingerichtet. Es wird auch die Klone und Fetches von Git umleiten, nicht nur die Web-Anfragen.