perlgit – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

perlgit – Detaillierte Informationen über Git und das Perl-Repository

BESCHREIBUNG

Dieses Dokument enthält Details zur Verwendung von Git zur Entwicklung von Perl. Wenn Sie nur daran interessiert sind
Ich arbeite an einem schnellen Patch, siehe zuerst Perlhack. Dieses Dokument richtet sich an Personen, die
sind regelmäßige Mitwirkende an Perl, darunter auch solche mit Schreibzugriff auf das Git-Repository.

KLONEN REPOSITORY

Der gesamte Quellcode von Perl wird zentral in einem Git-Repository gespeichert perl5.git.perl.org.

Sie können einen schreibgeschützten Klon des Repositorys erstellen, indem Sie Folgendes ausführen:

% git clone git://perl5.git.perl.org/perl.git perl

Dies verwendet das Git-Protokoll (Port 9418).

Wenn Sie das Git-Protokoll aus Firewall-Gründen nicht nutzen können, können Sie auch über http klonen,
obwohl das viel langsamer ist:

% Git-Klon http://perl5.git.perl.org/perl.git perl

ARBEITEN MIT REPOSITORY

Sobald Sie in das Repository-Verzeichnis gewechselt sind, können Sie es inspizieren. Nach einem Klonen der
Das Repository enthält einen einzelnen lokalen Zweig, der auch der aktuelle Zweig ist.
wie durch das Sternchen angezeigt.

% Git-Zweig
*bluten

Wenn Sie den Schalter -a auf „Branch“ setzen, werden auch die Remote-Tracking-Zweige im angezeigt
Repository:

% git branch -a
*bluten
Ursprung/KOPF
Herkunft/Blute
...

Die Zweige, die mit „origin“ beginnen, entsprechen dem „git remote“, von dem Sie geklont haben
(der „Ursprung“ genannt wird). Jeder Zweig auf der Fernbedienung wird dadurch genau verfolgt
Geäst. Sie sollten NIEMALS an diesen Remote-Tracking-Zweigen arbeiten. Das tust du immer nur
in einer örtlichen Filiale arbeiten. Lokale Zweige können so konfiguriert werden, dass sie automatisch (bei Pull) von einem zusammengeführt werden
ausgewiesene Remote-Tracking-Zweigstelle. Dies ist beim Standardzweig „blead“ der Fall
wird so konfiguriert, dass er aus dem Remote-Tracking-Zweig „origin/blead“ zusammengeführt wird.

Sie können die letzten Commits sehen:

% Git-Protokoll

Und ziehen Sie neue Änderungen aus dem Repository und aktualisieren Sie Ihr lokales Repository (muss sauber sein).
zuerst)

% git pull

Angenommen, wir befinden uns unmittelbar nach einem Pull auf dem Zweig „blead“, wäre dieser Befehl mehr
oder weniger gleichwertig mit:

% git fetch
% git merge origin/blead

In der Tat, wenn Sie Ihr lokales Repository aktualisieren möchten, ohne Ihre Arbeit zu beeinträchtigen
Verzeichnis, das Sie tun:

% git fetch

Und wenn Sie Ihre Remote-Tracking-Zweige für alle definierten Remotes aktualisieren möchten
gleichzeitig können Sie tun

% Git-Remote-Update

Keiner dieser beiden letzten Befehle aktualisiert Ihr Arbeitsverzeichnis, beide jedoch
Aktualisieren Sie die Remote-Tracking-Zweige in Ihrem Repository.

So erstellen Sie eine lokale Verzweigung einer Remote-Verzweigung:

% git checkout -b maint-5.10 origin/maint-5.10

So wechseln Sie zurück zu Blead:

% git checkout blead

Erkenntnis deine Status
Der am häufigsten verwendete Git-Befehl wird wahrscheinlich sein

% Git-Status

Dieser Befehl erzeugt als Ausgabe eine Beschreibung des aktuellen Status des Repositorys.
einschließlich geänderter Dateien und nicht ignorierter, nicht verfolgter Dateien, und außerdem wird es angezeigt
Dinge wie die Dateien, die für den nächsten Commit bereitgestellt wurden, und normalerweise einige nützliche
Informationen darüber, wie man Dinge ändern kann. Zum Beispiel Folgendes:

$ Git-Status
# Auf Astblut
# Ihr Zweig ist um 1 Commit vor „origin/blead“.
#
# Zu übernehmende Änderungen:
# (verwenden Sie „git reset HEAD ... "zu entbühnen)
#
# geändert: pod/perlgit.pod
#
# Geändert, aber nicht aktualisiert:
# (verwenden Sie „git add ..." um zu aktualisieren, was festgeschrieben wird)
#
# geändert: pod/perlgit.pod
#
# Nicht verfolgte Dateien:
# (verwenden Sie „git add ..., um in das einzubeziehen, was begangen wird)
#
# absichtlich.untracked

Dies zeigt, dass an diesem Dokument Änderungen vorgenommen wurden, die zur Festschreibung bereitgestellt wurden, und dass dies der Fall war
Weitere Änderungen im Arbeitsverzeichnis wurden noch nicht durchgeführt. Es zeigt auch, dass es eine gab
nicht verfolgte Datei im Arbeitsverzeichnis, und wie Sie sehen können, wird gezeigt, wie man alles ändert
Das. Es zeigt auch, dass es einen Commit im Arbeitszweig „blead“ gibt, der dies nicht getan hat
wurde noch nicht auf die „Ursprungs“-Fernbedienung geschoben. HINWEIS: dass diese Ausgabe auch das ist, was Sie als sehen
Vorlage, wenn Sie keine Nachricht an „git commit“ bereitstellen.

Patch Arbeitsablauf.
Bitte lesen Sie zunächst perlhack, um Einzelheiten zum Hacken des Perl-Kerns zu erfahren. Dieses Dokument deckt ab
viele Details, wie man einen guten Patch erstellt.

Wenn Sie bereits über ein Perl-Repository verfügen, sollten Sie sicherstellen, dass Sie sich auf dem befinden bluten Ast,
und Ihr Repository ist auf dem neuesten Stand:

% git checkout blead
% git pull

Es ist vorzuziehen, gegen die neueste Blead-Version zu patchen, da diese neu ist
Die Entwicklung erfolgt für alle Änderungen außer kritischen Fehlerbehebungen. Kritische Fehlerbehebungspatches
ist bei den zuständigen Hauptniederlassungen zu beantragen bzw. mit einem Vermerk einzureichen
Angabe aller Zweige, in denen der Fix angewendet werden soll.

Da wir nun alles auf dem neuesten Stand haben, müssen wir dafür einen temporären neuen Zweig erstellen
ändert sich und wechselt hinein:

% git checkout -b orange

Das ist die Kurzform von

% Git-Zweig orange
% Git Checkout Orange

Das Erstellen eines Themenzweigs erleichtert den Betreuern das Rebasieren oder erneute Zusammenführen
Der Meister plädierte für eine linearere Geschichte. Wenn Sie nicht an einem Themenzweig arbeiten, der
Der Betreuer muss Ihre Änderungen manuell auf dem Blei auswählen, bevor sie angewendet werden können.

Das wird dazu führen, dass Sie auf Perl5-Portern schimpfen, also tun Sie das nicht. Toll sein.

Nehmen Sie dann Ihre Änderungen vor. Wenn beispielsweise Leon Brocard seinen Namen in Orange Brocard ändert,
wir sollten seinen Namen in der AUTHORS-Datei ändern:

% perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTOREN

Sie können sehen, welche Dateien geändert wurden:

% Git-Status
# Am Ast orange
# Zu übernehmende Änderungen:
# (verwenden Sie „git reset HEAD ... "zu entbühnen)
#
# geändert: AUTOREN
#

Und Sie können die Änderungen sehen:

% git diff
diff --git a/AUTHORS b/AUTHORS
index 293dd70..722c93e 100644
--- a/AUTOREN
+++ b/AUTOREN
@@ -541,7 +541,7 @@ Lars Hecking[E-Mail geschützt] >
Laszlo Molnar[E-Mail geschützt] >
Leif Huhn[E-Mail geschützt] >
Len Johnson[E-Mail geschützt] >
-Leon Brocard[E-Mail geschützt] >
+Orange Brocard[E-Mail geschützt] >
Les Peters[E-Mail geschützt] >
Lesley Binks[E-Mail geschützt] >
Lincoln D. Stein[E-Mail geschützt] >

Übertragen Sie nun Ihre Änderung lokal:

% git commit -a -m 'Leon Brocard in Orange Brocard umbenennen'
Erstellter Commit 6196c1d: Benennen Sie Leon Brocard in Orange Brocard um
1 Dateien geändert, 1 Einfügungen(+), 1 Löschungen(-)

Die Option „-a“ wird verwendet, um alle Dateien einzuschließen, die GIT-Tracks enthalten, die Sie geändert haben. Wenn um
Wenn Sie dieses Mal nur einige der Dateien festschreiben möchten, an denen Sie gearbeitet haben, können Sie diese weglassen
„-a“ und verwenden Sie den Befehl „git add FILE ... " bevor Sie das Commit durchführen.
Mit „git add --interactive“ können Sie sogar nur Teile von Dateien statt aller Dateien festschreiben
die Veränderungen in ihnen.

Die Option „-m“ wird verwendet, um die Commit-Nachricht anzugeben. Wenn Sie es weglassen, öffnet Git eine
Texteditor, mit dem Sie die Nachricht interaktiv verfassen können. Dies ist nützlich, wenn sich Änderungen ergeben
sind komplexer als das hier gegebene Beispiel, und je nach Herausgeber muss man das wissen
Die erste Zeile der Commit-Nachricht überschreitet nicht die zulässige Höchstlänge von 50 Zeichen.

Sobald Sie mit dem Schreiben Ihrer Commit-Nachricht fertig sind und Ihren Editor verlassen haben, beginnt Git mit dem Schreiben
Ihr Wechsel auf die Festplatte und sagt Ihnen so etwas:

Commit daf8e63 erstellt: Git-Status und Dinge über Fernbedienungen erklären
1 Dateien geändert, 83 Einfügungen(+), 3 Löschungen(-)

Wenn Sie „git status“ erneut ausführen, sollten Sie etwa Folgendes sehen:

% Git-Status
# Auf Astblut
# Ihr Zweig liegt 2 Commits vor „origin/blead“.
#
# Nicht verfolgte Dateien:
# (verwenden Sie „git add ..., um in das einzubeziehen, was begangen wird)
#
# absichtlich.untracked
Es wurde nichts zum Festschreiben hinzugefügt, aber es sind nicht verfolgte Dateien vorhanden (verwenden Sie „git add“, um sie zu verfolgen)

Überprüfen Sie im Zweifelsfall Ihren Status und lesen Sie ihn sorgfältig durch, bevor Sie etwas anderes tun
Fragen werden direkt durch die Git-Status-Ausgabe beantwortet.

Sie können Ihr letztes Commit überprüfen mit:

% git show HEAD

Und wenn Sie mit der Beschreibung oder dem Patch selbst nicht zufrieden sind, können Sie ihn reparieren
indem Sie die Dateien noch einmal bearbeiten und dann Folgendes ausgeben:

% git commit -a --amend

Jetzt sollten Sie eine Patch-Datei für alle Ihre lokalen Änderungen erstellen:

% git format-patch -M blead..
0001-Rename-Leon-Brocard-to-Orange-Brocard.patch

Oder für viele Änderungen, z. B. aus einem Themenzweig:

% git format-patch --stdout -M blead.. > topic-branch-changes.patch

Sie sollten nun eine E-Mail an senden [E-Mail geschützt] <mailto:[E-Mail geschützt] > mit a
Beschreiben Sie Ihre Änderungen und fügen Sie diese Patchdatei als Anhang bei. Zusätzlich zu
E-Mails an Perlbug werden von RT verfolgt und automatisch an Perl5-Porter weitergeleitet
(mit manueller Moderation, bitte haben Sie etwas Geduld). Sie sollten Patches nur an senden
[E-Mail geschützt] <mailto:[E-Mail geschützt] > direkt, wenn der Patch noch nicht fertig ist
anzuwenden, aber zur Diskussion gedacht.

Bitte nicht verwenden git-send-email(1) um Ihren Patch zu versenden. Weitere Informationen finden Sie unter Senden von Patch-E-Mails
Informationen.

Wenn Sie Ihren temporären Zweig löschen möchten, können Sie dies wie folgt tun:

% git checkout blead
% git branch -d orange
Fehler: Der Zweig „orange“ ist kein Vorfahre Ihres aktuellen HEAD.
Wenn Sie sicher sind, dass Sie es löschen möchten, führen Sie „git branch -D orange“ aus.
% git branch -D orange
Gelöschter Zweig orange.

Festschreiben deine Änderungen
Angenommen, Sie möchten alle von Ihnen vorgenommenen Änderungen als einzelne atomare Einheit festschreiben,
Führen Sie diesen Befehl aus:

% git commit -a

(Dieses „-a“ weist Git an, jede Datei, die Sie geändert haben, zu diesem Commit hinzuzufügen. Neue Dateien nicht
automatisch zu Ihrem Commit hinzugefügt, wenn Sie „commit -a“ verwenden, wenn Sie Dateien hinzufügen oder hinzufügen möchten
Wenn Sie einige, aber nicht alle Ihrer Änderungen festschreiben möchten, schauen Sie sich die Dokumentation für „git add“ an.)

Git startet Ihren bevorzugten Texteditor, sodass Sie eine Commit-Nachricht dafür erstellen können
dein Wechselgeld. Weitere Informationen darüber, was ein Gut ausmacht, finden Sie unter „Commit-Nachricht“ in Perlhack
Commit-Nachricht.

Sobald Sie mit dem Schreiben Ihrer Commit-Nachricht fertig sind und Ihren Editor verlassen haben, beginnt Git mit dem Schreiben
Ihr Wechsel auf die Festplatte und sagt Ihnen so etwas:

Commit daf8e63 erstellt: Git-Status und Dinge über Fernbedienungen erklären
1 Dateien geändert, 83 Einfügungen(+), 3 Löschungen(-)

Wenn Sie „git status“ erneut ausführen, sollten Sie etwa Folgendes sehen:

% Git-Status
# Auf Astblut
# Ihr Zweig liegt 2 Commits vor „origin/blead“.
#
# Nicht verfolgte Dateien:
# (verwenden Sie „git add ..., um in das einzubeziehen, was begangen wird)
#
# absichtlich.untracked
Es wurde nichts zum Festschreiben hinzugefügt, aber es sind nicht verfolgte Dateien vorhanden (verwenden Sie „git add“, um sie zu verfolgen)

Überprüfen Sie im Zweifelsfall Ihren Status und lesen Sie ihn sorgfältig durch, bevor Sie etwas anderes tun
Fragen werden direkt durch die Git-Status-Ausgabe beantwortet.

Rechnungserstellung Flicken E-Mails
Nachdem Sie Ihren Patch generiert haben, sollten Sie ihn an senden [E-Mail geschützt] (wie besprochen in
(siehe vorheriger Abschnitt) mit einem normalen Mail-Client als Anhang, zusammen mit einer Beschreibung
des Patches.

Du sollen nicht - git-send-email(1) um mit generierte Patches zu versenden Git-Format-Patch(1). Das
RT-Ticketing-System lebt dahinter [E-Mail geschützt] respektiert nicht den Inline-Inhalt von
Das Senden eines Inline-Patches per E-Mail an RT garantiert, dass Ihr Patch zerstört wird.

Möglicherweise lädt jemand Ihren Patch von RT herunter, wodurch der Betreff (die erste Zeile) angezeigt wird
der Commit-Nachricht) weggelassen wird. Ein Beispiel finden Sie unter RT #74192 und Commit a4583001.
Alternativ kann jemand Ihren Patch von RT anwenden, nachdem er in seinem Postfach angekommen ist
Zu diesem Zeitpunkt hat RT den Inline-Inhalt der Nachricht geändert. Siehe RT #74532 und
Übertragen Sie f9bcfeac als schlechtes Beispiel für diesen Fehlermodus.

A beachten on abgeleitet Dateien
Beachten Sie, dass viele Dateien in der Distribution abgeleitet sind. Vermeiden Sie daher Patches
Git sieht die daran vorgenommenen Änderungen nicht und der Build-Prozess überschreibt sie. Patchen Sie das
stattdessen Originale. Die meisten Dienstprogramme (wie Perldoc) fallen in diese Kategorie, z. B. Patch
utils/perldoc.PL statt utils/perldoc. Erstellen Sie auch keine Patches für Dateien
unter $src_root/ext aus ihren Kopien in $install_root/lib. Wenn Sie sich nicht sicher sind
der richtige Speicherort einer Datei, die möglicherweise beim Erstellen der Quelle kopiert wurde
Informationen zur Verteilung finden Sie im „MANIFEST“.

Reinigung a arbeiten, Verzeichnis
Der Befehl „git clean“ kann mit unterschiedlichen Argumenten als Ersatz für „make“ verwendet werden
sauber".

Um Ihr Arbeitsverzeichnis auf einen makellosen Zustand zurückzusetzen, können Sie Folgendes tun:

% git clean -dxf

Beachten Sie jedoch, dass dadurch ALLE nicht verfolgten Inhalte gelöscht werden. Sie können verwenden

% git clean -Xf

um alle ignorierten, nicht verfolgten Dateien zu entfernen, z. B. Build- und Test-Nebenprodukte, aber alle übrig zu lassen
manuell erstellte Dateien allein.

Wenn Sie nur einige nicht festgeschriebene Änderungen abbrechen möchten, können Sie „git checkout“ verwenden und diese übergeben
eine Liste der Dateien, die zurückgesetzt werden sollen, oder „git checkout -f“, um sie alle zurückzusetzen.

Wenn Sie einen oder mehrere Commits abbrechen möchten, können Sie „git reset“ verwenden.

Halbieren
„git“ bietet eine integrierte Möglichkeit, zu bestimmen, welcher Commit für die Einführung von a verantwortlich gemacht werden soll
gegebener Fehler. „git bisect“ führt eine binäre Suche im Verlauf durch, um den ersten Fehler zu finden
begehen. Es ist schnell, leistungsstark und flexibel, erfordert jedoch einige Einrichtungs- und Automatisierungsschritte
Für den Prozess ist ein zusätzliches Shell-Skript erforderlich.

Der Kern stellt ein Wrapper-Programm bereit, Porting/bisect.pl, was versucht, dies zu vereinfachen
so einfach wie möglich zu machen, wie das Ausführen eines Perl-Einzeilers. Zum Beispiel, wenn Sie
Ich möchte wissen, wann dies zu einem Fehler wurde:

perl -e 'mein $a := 2'

Sie führen einfach Folgendes aus:

.../Porting/bisect.pl -e 'my $a := 2;'

Mit „bisect.pl“ lässt sich das mit einem Befehl (und ohne weitere Dateien) leicht herausfinden

· Welcher Commit hat dazu geführt, dass dieser Beispielcode kaputt ging?

· Welcher Commit hat dazu geführt, dass dieser Beispielcode funktioniert?

· Welcher Commit hat die erste Datei hinzugefügt, die dieser Regex entspricht?

· Welcher Commit hat die letzte Datei entfernt, die dieser Regex entspricht?

normalerweise ohne wissen zu müssen, welche Perl-Versionen als Start- und Endrevisionen verwendet werden sollen,
as bisect.pl sucht automatisch nach der frühesten stabilen Version, für die der Test durchgeführt wurde
Fall geht vorbei. Führen Sie „Porting/bisect.pl --help“ aus, um die vollständige Dokumentation und Anleitungen zu erhalten
Legen Sie die Optionen „Konfigurieren“ und „Erstellungszeit“ fest.

Wenn Sie mehr Flexibilität benötigen als Porting/bisect.pl zu bieten hat, musst du laufen
„git bisect“ dich selbst. Am nützlichsten ist es, „git bisect run“ zu verwenden, um das Gebäude zu automatisieren
und Testen von Perl-Revisionen. Dazu benötigen Sie ein Shell-Skript, das „git“ aufrufen kann
Testen Sie eine bestimmte Revision. Ein Beispielskript ist Porting/bisect-example.sh, welche du
kopieren sollte aussen des Repositorys, da der Bisect-Prozess den Status auf a zurücksetzt
Saubere Kasse, während sie läuft. Bei den folgenden Anweisungen wird davon ausgegangen, dass Sie es als kopiert haben ~/run und
habe es dann entsprechend bearbeitet.

Sie gelangen zunächst in den Halbierungsmodus mit:

% git bisect start

Wenn der Fehler beispielsweise auf „HEAD“ vorhanden ist, aber nicht in 5.10.0, wird „git“ davon erfahren
dies, wenn Sie Folgendes eingeben:

% git bisect schlecht
% Git Bisect Good Perl-5.10.0
Halbierung: Danach müssen noch 853 Revisionen getestet werden

Dies führt dazu, dass der mittlere Commit zwischen „HEAD“ und „perl-5.10.0“ überprüft wird. Du kannst
Führen Sie dann den Halbierungsvorgang aus mit:

% git bisect run ~/run

Wenn der erste fehlerhafte Commit isoliert ist, teilt Ihnen „git bisect“ Folgendes mit:

ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 is first bad commit
commit ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5
Autor: Dave Mitchell[E-Mail geschützt] >
Datum: Sa. 9. Februar 14:56:23 2008 +0000

[perl #49472] Attribute + Unbekannter Fehler
...

Halbieren Sie den Lauferfolg

Mit „git bisect log“ und „git bisect visualize“ können Sie einen Blick in den Bisecting-Prozess werfen.
Mit „Git Bisect Reset“ verlassen Sie den Bisect-Modus.

Bitte beachten Sie, dass der erste „gute“ Zustand ein Vorfahre des ersten „schlechten“ Zustands sein muss. Wenn
Sie möchten nach dem Commit suchen gelöst Irgendein Fehler, Sie müssen Ihren Testfall negieren
(dh beenden Sie mit 1, wenn OK, und 0, wenn nicht) und markieren Sie weiterhin die Untergrenze als „gut“ und die
Obermaterial als „schlecht“. Der „erste schlechte Commit“ ist dann als „erster Commit“ zu verstehen
wo der Fehler behoben ist".

„git help bisect“ bietet viel mehr Informationen darüber, wie Sie Ihre binären Suchen optimieren können.

Betreff Geäst und Umschreibung Geschichte
Einzelne Committer sollten unten Themenzweige erstellen dein Name/some_descriptive_name.
Andere Committer sollten sich beim Ersteller eines Themenzweigs erkundigen, bevor sie Änderungen daran vornehmen
es.

Der einfachste Weg, einen Remote-Themenzweig zu erstellen, der auf allen Git-Versionen funktioniert, ist:
Schieben Sie den aktuellen Kopf als neuen Zweig auf die Fernbedienung und prüfen Sie ihn dann lokal:

$ branch="$yourname/$some_descriptive_name"
$ git push origin HEAD:$branch
$ git checkout -b $branch origin/$branch

Benutzer von Git 1.7 oder neuer können dies auf eine offensichtlichere Weise tun:

$ branch="$yourname/$some_descriptive_name"
$ git checkout -b $branch
$ git push origin -u $branch

Wenn Sie nicht der Ersteller von sind dein Name/some_descriptive_name, werden Sie vielleicht manchmal finden
dass der ursprüngliche Autor die Geschichte des Zweigs bearbeitet hat. Es gibt viele gute Gründe
dafür. Manchmal basiert ein Autor den Zweig einfach auf eine neuere Quelle um
Punkt. Manchmal hat ein Autor möglicherweise einen Fehler in einem frühen Commit gefunden, den er durchgeführt hat
Ich wollte das Problem beheben, bevor ich den Zweig zu Blead zusammenführte.

Derzeit ist das Master-Repository so konfiguriert, dass Zusammenführungen ohne schnellen Vorlauf verboten sind. Das
bedeutet, dass die darin enthaltenen Zweige nicht in einem einzigen Schritt umbasiert und gepusht werden können.

Nur so können Sie jemals den Verlauf eines gepushten Zweigs umbasieren oder ändern
besteht darin, es zu löschen und als neuen Zweig unter demselben Namen zu verschieben. Bitte denken Sie sorgfältig darüber nach
darüber, dies zu tun. Möglicherweise ist es besser, Ihre Zweige nacheinander so umzubenennen, dass dies der Fall ist
Es ist für andere, die mit Ihnen zusammenarbeiten, einfacher, ihre lokalen Änderungen auf die neuen zu übertragen
Ausführung. (XXX: erklärungsbedürftig).

Wenn Sie einen persönlichen Themenzweig umbasieren möchten, müssen Sie Ihr vorhandenes Thema löschen
verzweigen und als neue Version davon pushen. Sie können dies über die folgende Formel tun (siehe
Weitere Informationen finden Sie in der Git-Push-Dokumentation (Erläuterung zu „Refspecs“), nachdem Sie dies getan haben
Ihren Zweig neu gegründet:

# erster Rebase
$ git checkout $user/$topic
$git fetch
$ git rebase origin/blead

# dann „löschen und pushen“
$ git push origin :$user/$topic
$ git push origin $user/$topic

Anmerkungen: Auf Repository-Ebene ist es verboten, einen der „primären“ Zweige zu löschen.
Das ist jeder Zweig, der zu „m!^(blead|maint|perl)!“ passt. Jeder Versuch, dies zu tun, führt zu
git erzeugt einen Fehler wie diesen:

$ git push origin :blead
*** Es ist verboten, Blead-/Maint-Zweige in diesem Repository zu löschen
Fehler: Hooks/Update mit Fehlercode 1 beendet
Fehler: Hook weigerte sich, refs/heads/blead zu aktualisieren
Zu ssh://perl5.git.perl.org/perl
! [aus der Ferne abgelehnt] Blay (Hook abgelehnt)
Fehler: Einige Refs konnten nicht an „ssh://perl5.git.perl.org/perl“ gesendet werden.

Aus politischen Gründen tun wir das nicht Bearbeiten Sie den Verlauf der Blead- und Maint-*-Zweige. Wenn ein
Sollte sich ein Tippfehler (oder Schlimmeres) in einen Commit von blead oder maint-* einschleichen, werden wir ihn in einem anderen Commit beheben.
Die einzigen Arten von Aktualisierungen, die in diesen Zweigen zulässig sind, sind „Fast-Forward“-Aktualisierungen, bei denen alle
Geschichte bleibt erhalten.

Annotierte Tags im kanonischen perl.git-Repository werden niemals gelöscht oder geändert.
Überlegen Sie lange und gründlich, ob Sie ein lokales Tag auf perl.git übertragen möchten, bevor Sie dies tun
Also. (Das Übertragen von Tags ohne Anmerkungen ist nicht zulässig.)

Transplantate
Der Perl-Verlauf enthält einen Fehler, der bei der Konvertierung nicht erkannt wurde: Es wurde eine Zusammenführung durchgeführt
in der Historie zwischen Blead und Maint-5.10 aufgezeichnet, wo tatsächlich keine Zusammenführung stattgefunden hat. Fällig
Aufgrund der Natur von Git ist es jetzt unmöglich, dies im öffentlichen Repository zu beheben. Du kannst
Entfernen Sie diese Fehlzusammenführung lokal, indem Sie die folgende Zeile zu Ihrer „.git/info/grafts“-Datei hinzufügen.
Datei:

296f12bbbbaa06de9be9d09d3dcf8f4528898a49 434946e0cb7a32589ed92d18008aaa1d88515930

Es ist besonders wichtig, diese Transplantatlinie zu haben, wenn in diesem Bereich eine Halbierung vorgenommen wird
der fraglichen „Zusammenführung“.

SCHREIBEN ACCESS TO GIT REPOSITORY

Sobald Sie über Schreibzugriff verfügen, müssen Sie die URL für die Ursprungsfernbedienung ändern
Schieben ermöglichen. Bearbeiten .git / config an. Nach der Installation können Sie HEIC-Dateien mit der git-config(1) Befehl:

% git config remote.origin.url ssh://perl5.git.perl.org/perl.git

Sie können auch Ihren Benutzernamen und Ihre E-Mail-Adresse einrichten. Die meisten Menschen tun dies weltweit einmal
in ihrer ~ / .gitconfig indem Sie etwas tun wie:

% git config --global user.name „AEvar Arnfjoer` Bjarmason“
% git config --global user.email [E-Mail geschützt]

Wenn Sie dies jedoch nur für Perl überschreiben möchten, führen Sie etwas wie das aus
im Anschluss perl:

% git config user.email [E-Mail geschützt]

Es ist auch möglich, „origin“ als Git-Remote beizubehalten und ein neues Remote für den SSH-Zugriff hinzuzufügen:

% git remote add camel perl5.git.perl.org:/perl.git

Dadurch können Sie Ihr lokales Repository durch Abrufen von „Origin“ aktualisieren, was schneller ist
und erfordert nicht, dass Sie sich authentifizieren und Ihre Änderungen mit dem „Kamel“ zurückschieben
Fernbedienung:

% Git Fetch Camel
% Git Push Camel

Der Befehl „fetch“ aktualisiert nur die „camel“-Referenzen, wie es die Objekte selbst tun sollten
wurde beim Abrufen von „Origin“ abgerufen.

Akzeptieren a Flicken
Wenn Sie eine mit dem obigen Abschnitt generierte Patch-Datei erhalten haben, sollten Sie es ausprobieren
der Patch.

Zuerst müssen wir für diese Änderungen einen temporären neuen Zweig erstellen und in diesen wechseln:

% git checkout -b experimentell

Patches, die mit „git format-patch“ formatiert wurden, werden mit „git am“ angewendet:

% git am 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch
Anwenden: Benennen Sie Leon Brocard in Orange Brocard um

Wenn nur ein Rohdiff bereitgestellt wird, ist es auch möglich, diesen zweistufigen Prozess zu verwenden:

% git apply bugfix.diff
% git commit -a -m "Einige Korrekturen" --author="Dieser Typ[E-Mail geschützt] >"

Jetzt können wir die Änderung überprüfen:

% git show HEAD
commit b1b3dab48344cff6de4087efca3dbd63548ab5e2
Autor: Leon Brocard[E-Mail geschützt] >
Datum: Fr. 19. Dezember 17:02:59 2008 +0000

Benennen Sie Leon Brocard in Orange Brocard um

diff --git a/AUTHORS b/AUTHORS
index 293dd70..722c93e 100644
--- a/AUTOREN
+++ b/AUTOREN
@@ -541,7 +541,7 @@ Lars Hecking[E-Mail geschützt] >
Laszlo Molnar[E-Mail geschützt] >
Leif Huhn[E-Mail geschützt] >
Len Johnson[E-Mail geschützt] >
-Leon Brocard[E-Mail geschützt] >
+Orange Brocard[E-Mail geschützt] >
Les Peters[E-Mail geschützt] >
Lesley Binks[E-Mail geschützt] >
Lincoln D. Stein[E-Mail geschützt] >

Wenn Sie ein Perl-Committer sind und der Meinung sind, dass der Patch gut ist, können Sie ihn dann einbinden
blead und dann in das Haupt-Repository verschieben:

% git checkout blead
% Git Merge experimentell
% git push origin blead

Wenn Sie Ihren temporären Zweig löschen möchten, können Sie dies wie folgt tun:

% git checkout blead
% git branch -d experimentell
Fehler: Der Zweig „experimentell“ ist kein Vorfahre Ihres aktuellen HEAD.
Wenn Sie sicher sind, dass Sie es löschen möchten, führen Sie „git branch -D experimentell“ aus.
% git branch -D experimentell
Zweig experimentell gelöscht.

Festschreiben zu bluten
Der Zweig „blead“ wird die nächste Produktionsversion von Perl sein.

Vor dem Schieben jedem Wenn Sie lokal Blut verlieren, ist es unglaublich wichtig, dass Sie einige davon durchführen
Dinge, damit nicht andere Täter mit Mistgabeln und Fackeln hinter dir her sind:

· Stellen Sie sicher, dass Sie eine gute Commit-Nachricht haben. Siehe „Commit-Nachricht“ in Perlhack für
Details.

· Führen Sie die Testsuite aus. Sie glauben vielleicht nicht, dass eine Tippfehlerkorrektur eine Testdatei beschädigen würde.
Du liegst falsch. Hier ist ein Beispiel dafür, wo es zu Problemen kam, wenn die Suite nicht ausgeführt wurde. A
Es wurde ein Patch eingereicht, der einige Tests zu einer vorhandenen .t-Datei hinzufügte. Es konnte nicht
wirkt sich möglicherweise auf alles andere aus, daher ist kein Test über die einzelne betroffene .t-Datei hinaus erforderlich.
Rechts? Die E-Mail-Adresse des Einreichers hatte sich jedoch seit der letzten E-Mail geändert
Dies führte dazu, dass andere Tests fehlschlugen. Ausführen des im angegebenen Testziels
Der nächste Punkt hätte dieses Problem behoben.

· Wenn Sie nicht die vollständige Testsuite ausführen, erstellen Sie zumindest „test_porting“. Dies wird ausgeführt
grundlegende Gesundheitsprüfungen. Um zu sehen, welche Vernunftprüfungen durchgeführt werden, werfen Sie einen Blick auf t/portieren.

· Wenn Sie Änderungen vornehmen, die Miniperl oder Kernroutinen mit unterschiedlichem Code betreffen
Pfade für Miniperl, stellen Sie sicher, dass Sie „make minitest“ ausführen. Dadurch werden Probleme behoben
Selbst die vollständige Testsuite wird nicht erkannt, da sie nur eine Teilmenge der Tests ausführt
Miniperl statt Perl.

On Verschmelzung und Umbasierung
Einfache, einmalige Commits, die an den „Blead“-Zweig übertragen werden, sollten einfache, anwendbare Commits sein
sauber. Mit anderen Worten: Sie sollten sicherstellen, dass Ihre Arbeit gegen den Strom ausgerichtet ist
Position des Bleis, sodass Sie ohne Zusammenführung zum Master-Repository zurückkehren können.

Manchmal bewegt sich das Blei, während Sie Ihre Änderungen erstellen oder testen. Wenn das
passiert, wird Ihr Push mit einer Meldung wie dieser abgelehnt:

Zu ssh://perl5.git.perl.org/perl.git
! [abgelehnt] blead -> blead (kein schneller Vorlauf)
Fehler: Einige Refs konnten nicht an „ssh://perl5.git.perl.org/perl.git“ gesendet werden.
Um zu verhindern, dass Sie den Verlauf verlieren, wurden nicht schnelle Aktualisierungen abgelehnt
Führen Sie die Remote-Änderungen zusammen (z. B. „git pull“), bevor Sie erneut drücken. Siehe die
Einzelheiten finden Sie im Abschnitt „Hinweis zum schnellen Vorlauf“ von „git push --help“.

Wenn das passiert, können Sie einfach zurückweisen Ihre Arbeit gegen die neue Position von Blead, wie
Dies (vorausgesetzt, Ihre Fernbedienung für das Master-Repository ist „p5p“):

$ git fetch p5p
$ git rebase p5p/blead

Sie werden sehen, dass Ihre Commits erneut angewendet werden, und Sie können dann sicher pushen.
Weitere Informationen zum Rebasing finden Sie in der Dokumentation zum Git-Rebase(1)
Befehl.

Für größere Mengen von Commits, die nur zusammen Sinn machen oder von a profitieren würden
Um den Zweck des Satzes zusammenzufassen, sollten Sie einen Merge-Commit verwenden. Sie sollten Ihre Arbeit erledigen
auf einem Themenzweig, den Sie regelmäßig gegen Blead rebasieren sollten, um sicherzustellen, dass Ihr
Der Code wird durch das Verschieben des Kabels nicht beschädigt. Wenn Sie mit Ihrer Arbeit fertig sind, führen Sie bitte a aus
Letzte Rebase und Test. Der lineare Verlauf geht bei jedem Commit verloren
Blei, aber ein abschließender Rebase macht den Verlauf wieder linear und macht ihn für die Zukunft einfacher
Betreuer, um zu sehen, was passiert ist. Rebasieren Sie wie folgt (vorausgesetzt, Ihre Arbeit war am
Zweig „committer/somework“):

$ git checkout committer/somework
$ git rebase blead

Dann können Sie es wie folgt in den Master einbinden:

$ Git Checkout Blead
$ git merge --no-ff --no-commit committer/somework
$ git commit -a

Die oben genannten Schalter verdienen eine Erklärung. „--no-ff“ zeigt an, dass auch wenn alle Ihre Arbeit
linear gegen Blead angewendet werden kann, sollte dennoch ein Merge-Commit vorbereitet werden. Das
stellt sicher, dass Ihre gesamte Arbeit als Seitenzweig angezeigt wird, in dem alle Commits zusammengeführt werden
in den Mainstream-Bereich durch den Merge-Commit.

„--no-commit“ bedeutet, dass das Merge-Commit ausgeführt wird bereit aber nicht begangen. Der Commit
wird dann tatsächlich ausgeführt, wenn Sie den nächsten Befehl ausführen, der Ihren Editor öffnet
um den Commit zu beschreiben. Ohne „--no-commit“ würde der Commit fast ohne erfolgen
nützliche Nachricht, die den Wert des Merge-Commits als erheblich verringern würde
Platzhalter für die Werkbeschreibung.

Erklären Sie bei der Beschreibung des Merge-Commits den Zweck des Zweigs und denken Sie daran
Diese Beschreibung wird wahrscheinlich vom späteren Release-Ingenieur bei der Überprüfung verwendet
nächstes Perldelta-Dokument.

Festschreiben zu Wartung Versionen
Wartungsversionen sollten nur geändert werden, um kritische Fehlerbehebungen hinzuzufügen, siehe Perlpolicy.

Um sich auf eine Wartungsversion von Perl festzulegen, müssen Sie einen lokalen Tracking-Zweig erstellen:

% git checkout --track -b maint-5.005 origin/maint-5.005

Dadurch wird ein lokaler Zweig mit dem Namen „maint-5.005“ erstellt, der den Remote-Zweig verfolgt
„origin/maint-5.005“. Dann können Sie wie zuvor ziehen, festschreiben, zusammenführen und pushen.

Sie können Commits auch aus Blead und einem anderen Zweig herauspicken, indem Sie den Befehl „git
Cherry-Pick“-Befehl. Es wird empfohlen, den zu verwenden -x Option zum „Git Cherry-Pick“ in der Reihenfolge
um den SHA1 des ursprünglichen Commits in der neuen Commit-Nachricht aufzuzeichnen.

Bevor Sie Änderungen an einer Hauptversion vornehmen, stellen Sie sicher, dass Sie die Schritte in ausgeführt haben
„Verpflichtung zum Bluten“ oben.

Vereinigung für a Filiale GitHub
Obwohl wir die Übermittlung von Patches über GitHub nicht empfehlen, wird dies dennoch passieren.
Hier finden Sie eine Anleitung zum Zusammenführen von Patches aus einem GitHub-Repository.

% git remote add avar git://github.com/avar/perl.git
% git fetch avar

Jetzt können Sie die Unterschiede zwischen Zweig und Blut erkennen:

% git diff avar/orange

Und Sie können die Commits sehen:

% git log avar/orange

Wenn Sie einem bestimmten Commit zustimmen, können Sie es auswählen:

% git cherry-pick 0c24b290ae02b2ab3304f51d5e11e85eb3659eae

Oder Sie könnten einfach den gesamten Zweig zusammenführen, wenn Ihnen alles gefällt:

% git merge avar/orange

Und dann zurück zum Repository pushen:

% git push origin blead

Die richtigen a Rauch mich Filiale zu Test Änderungen
Manchmal wirkt sich eine Änderung auf Codepfade aus, die Sie nicht direkt auf den Betriebssystemen testen können
Ihnen zur Verfügung und es wäre ratsam, Benutzer anderer Betriebssysteme die Änderung vorher testen zu lassen
Du begehst es, zu bluten.

Glücklicherweise gibt es eine Möglichkeit, Ihr Kleingeld auf verschiedenen Betriebssystemen einem Rauchtest zu unterziehen: Schieben Sie es auf ein
„smoke-me“-Zweig und warten Sie darauf, dass bestimmte automatische Rauchtester die Ergebnisse melden
ihre Betriebssysteme.

Das Vorgehen hierfür ist ungefähr wie folgt (am Beispiel von Tonyc's Smoke-
mein Zweig namens win32stat):

Erstellen Sie zunächst einen lokalen Zweig und wechseln Sie zu diesem:

% git checkout -b win32stat

Nehmen Sie einige Änderungen vor, erstellen Sie Perl, testen Sie Ihre Änderungen und übertragen Sie sie dann auf Ihre lokale Version
Zweig. Schieben Sie dann Ihre lokale Filiale in eine entfernte Smoke-Me-Filiale:

% git push origin win32stat:smoke-me/tonyc/win32stat

Jetzt können Sie wieder lokal auf Blead umschalten:

% git checkout blead

und arbeiten Sie weiter an anderen Dingen, während Sie ein oder zwei Tage warten, und behalten Sie dabei die Dinge im Auge
Ergebnisse für Ihre Smoke-Me-Filiale unter
<http://perl.develop-help.com/?b=smoke-me/tonyc/win32state>.

Wenn alles in Ordnung ist, aktualisieren Sie Ihren Blead-Zweig:

% git pull

Schauen Sie sich dann Ihren Smoke-Me-Zweig noch einmal an und stützen Sie ihn auf Blea:

% git rebase blead win32stat

Wechseln Sie nun zurück zu Blead und verschmelzen Sie Ihren Smoke-Me-Zweig darin:

% git checkout blead
% git merge win32stat

Wie bereits beschrieben, sollten Sie dies tun, wenn es in Ihrem Smoke-Me-Zweig viele Änderungen gibt
Bereiten Sie einen Merge-Commit vor, in dem Sie mithilfe von einen Überblick über diese Änderungen geben können
folgenden Befehl anstelle des letzten Befehls oben:

% git merge win32stat --no-ff --no-commit

Sie sollten jetzt Perl erstellen und Ihre (zusammengeführten) Änderungen ein letztes Mal testen (idealerweise ausführen).
gesamte Testsuite, aber wenn das nicht gelingt, führen Sie zumindest die aus t/porting/*.t Tests) vor dem Drücken
Ihre Änderungen wie gewohnt:

% git push origin blead

Abschließend sollten Sie dann den Remote-Smoke-Me-Zweig löschen:

% git push origin :smoke-me/tonyc/win32stat

(was wahrscheinlich zu einer Warnung wie dieser führt, die ignoriert werden kann:

remote: fatal: mehrdeutiges Argument 'refs/heads/smoke-me/tonyc/win32stat':
Unbekannte Revision oder Pfad nicht im Arbeitsbaum.
remote: Verwenden Sie „--“, um Pfade von Revisionen zu trennen

) und löschen Sie dann Ihren lokalen Zweig:

% git branch -d win32stat

A beachten on Kamel und Dromedar
Die Committer haben SSH-Zugriff auf die beiden Server, die „perl5.git.perl.org“ bedienen. Einer ist
„perl5.git.perl.org“ selbst (Kamel), das das „Master“-Repository ist. Der zweite ist
„users.perl5.git.perl.org“ (Dromedar), das für allgemeine Tests verwendet werden kann und
Entwicklung. Dromedary synchronisiert den Git-Baum alle paar Minuten von Camel, das sollten Sie nicht tun
dort schieben. Beide Maschinen verfügen außerdem über einen vollständigen CPAN-Spiegel in /srv/CPAN, bitte nutzen Sie diesen. Zu
Teilen Sie Dateien mit der Öffentlichkeit, Dromedar dient Ihnen ~/public_html/ as
"http://users.perl5.git.perl.org/~yourlogin/"

Diese Hosts verfügen nach außen hin über ziemlich strenge Firewalls. Ausgehend, nur rsync, ssh und git
sind erlaubt. Für http und ftp können Sie verwenden http://webproxy:3128 als Proxy. Eingehend, die
Die Firewall versucht, Angriffe zu erkennen und IP-Adressen mit verdächtigen Aktivitäten zu blockieren. Das
Manchmal (aber sehr selten) gibt es Fehlalarme und Sie werden möglicherweise blockiert. Das schnellste
Eine Möglichkeit, die Blockierung aufzuheben, besteht darin, die Administratoren zu benachrichtigen.

Diese beiden Boxen sind Eigentum von booking.com und werden von booking.com gehostet und betrieben. Sie erreichen die
sysadmins in #p5p auf irc.perl.org oder per E-Mail an „[E-Mail geschützt] ".

Verwenden Sie Perlgit online über die Dienste von onworks.net