perlgit - Online in de cloud

PROGRAMMA:

NAAM

perlgit - Gedetailleerde informatie over git en de Perl-repository

PRODUCTBESCHRIJVING

Dit document geeft details over het gebruik van git om Perl te ontwikkelen. Als je gewoon geïnteresseerd bent
bezig met een snelle patch, zie eerst perlhack. Dit document is bedoeld voor mensen die
leveren regelmatig bijdragen aan Perl, inclusief degenen met schrijftoegang tot de git-repository.

KLONEN HET OPSLAGPLAATS

Alle broncode van Perl wordt centraal bewaard in een Git-repository op perl5.git.perl.org.

U kunt een alleen-lezen kloon van de repository maken door het volgende uit te voeren:

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

Dit maakt gebruik van het git-protocol (poort 9418).

Als je om firewall-redenen het git-protocol niet kunt gebruiken, kun je ook klonen via http,
hoewel dit veel langzamer is:

% git-kloon http://perl5.git.perl.org/perl.git perl

WERKEN MET HET OPSLAGPLAATS

Zodra u naar de repositorymap bent gegaan, kunt u deze inspecteren. Na een kloon van de
repository zal één lokale branch bevatten, die ook de huidige branch zal zijn,
zoals aangegeven door het sterretje.

% git-tak
* bloeden

Als u de schakelaar -a naar "branch" gebruikt, worden ook de takken voor het volgen op afstand in de
repository:

% git-tak -a
* bloeden
oorsprong/HOOFD
oorsprong/bloed
...

De branches die beginnen met "origin" komen overeen met de "git remote" waarvan je hebt gekloond
(die "oorsprong" wordt genoemd). Elke tak op de afstandsbediening wordt hierdoor exact gevolgd
takken. U mag NOOIT werken aan deze takken voor het volgen op afstand. Dat doe je alleen maar
werken in een lokale afdeling. Lokale vertakkingen kunnen worden geconfigureerd om automatisch samen te voegen (bij pull) vanaf a
aangewezen filiaal voor volgen op afstand. Dit is het geval met de standaardvertakking "blead", die
zal worden geconfigureerd om samen te voegen vanuit de externe volgtak "origin/blead".

Je kunt recente commits zien:

% git-logboek

En haal nieuwe wijzigingen uit de repository en update uw lokale repository (moet schoon zijn
eerste)

% git-pull

Ervan uitgaande dat we ons onmiddellijk na een pull op de tak "blead" bevinden, zou dit commando meer zijn
of minder gelijkwaardig aan:

% git ophalen
% git samenvoegoorsprong/blead

In feite als u uw lokale repository wilt bijwerken zonder uw werk aan te raken
map die je doet:

% git ophalen

En als u uw remote-tracking-filialen voor alle gedefinieerde afstandsbedieningen wilt bijwerken
tegelijkertijd kun je doen

% git externe update

Geen van deze laatste twee opdrachten zal uw werkmap bijwerken, maar beide wel
update de takken voor het volgen op afstand in uw repository.

Om een ​​lokale vertakking van een externe vertakking te maken:

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

Om terug te schakelen naar bloeden:

% git kassa bleed

Het vinden van uit jouw toestand
Het meest voorkomende git-commando dat je zult gebruiken zal waarschijnlijk zijn

% git-status

Dit commando produceert als uitvoer een beschrijving van de huidige status van de repository,
inclusief gewijzigde bestanden en niet-genegeerde, niet-bijgehouden bestanden, en bovendien zal het worden weergegeven
dingen zoals welke bestanden zijn geënsceneerd voor de volgende commit, en meestal enkele nuttige
informatie over hoe u dingen kunt veranderen. Bijvoorbeeld het volgende:

$ git-status
# Op takbloeding
# Jouw branch ligt 1 commit voor op 'origin/blead'.
#
# Wijzigingen die moeten worden vastgelegd:
# (gebruik "git reset HEAD ..." om uit te voeren)
#
# aangepast: pod/perlgit.pod
#
# Gewijzigd maar niet bijgewerkt:
# (gebruik "git add ..." om bij te werken wat er wordt vastgelegd)
#
# aangepast: pod/perlgit.pod
#
# Niet-bijgehouden bestanden:
# (gebruik "git add ..." om op te nemen in wat zal worden vastgelegd)
#
# opzettelijk.niet gevolgd

Dit laat zien dat er wijzigingen in dit document waren die waren voorbereid voor commit, en dat die er ook waren
verdere wijzigingen in de werkmap zijn nog niet doorgevoerd. Hieruit blijkt ook dat er sprake was van een
niet-bijgehouden bestand in de werkmap, en zoals u kunt zien, wordt weergegeven hoe u dit allemaal kunt wijzigen
dit. Het laat ook zien dat er één commit is op de werkende branch "blead" die dat niet heeft gedaan
is nog niet naar de "oorsprong"-afstandsbediening geduwd. NOTITIE: dat deze uitvoer ook is wat u ziet als een
sjabloon als je geen bericht aan "git commit" geeft.

Patch workflow
Lees eerst perlhack voor details over het hacken van de Perl-kern. Dat document dekt
veel details over hoe je een goede patch kunt maken.

Als u al een Perl-repository heeft, moet u ervoor zorgen dat u zich op de bloeden Afdeling,
en uw repository is up-to-date:

% git kassa bleed
% git-pull

Het verdient de voorkeur om te patchen tegen de nieuwste blead-versie, aangezien dit nieuw is
ontwikkeling vindt plaats voor alle wijzigingen behalve kritieke bugfixes. Kritieke bugfix-patches
dient te worden ingediend tegen de betreffende hoofdvestigingen, dan wel te worden ingediend met een aantekening
met vermelding van alle takken waar de fix moet worden toegepast.

Nu we alles up-to-date hebben, moeten we hiervoor tijdelijk een nieuwe vestiging aanmaken
verandert en schakelt ernaar over:

% git checkout -b oranje

wat de korte vorm is van

% git tak oranje
% git afrekenen oranje

Het creëren van een onderwerpbranch maakt het makkelijker voor de beheerders om te rebasen of er weer in samen te voegen
het meesterbleed voor een meer lineaire geschiedenis. Als u niet aan een onderwerp werkt, vertakt u de
De beheerder moet uw wijzigingen handmatig op Blead selecteren voordat ze kunnen worden toegepast.

Dat zal ervoor zorgen dat je wordt uitgescholden voor perl5-porters, dus doe dat niet. Geweldig zijn.

Breng vervolgens uw wijzigingen aan. Als Leon Brocard bijvoorbeeld zijn naam verandert in Orange Brocard,
we moeten zijn naam veranderen in het AUTHORS-bestand:

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

U kunt zien welke bestanden zijn gewijzigd:

% git-status
# Op tak oranje
# Wijzigingen die moeten worden vastgelegd:
# (gebruik "git reset HEAD ..." om uit te voeren)
#
# gewijzigd: AUTEURS
#

En je kunt de veranderingen zien:

% git diff
diff --git a/AUTEURS b/AUTEURS
index 293dd70..722c93e 100644
--- a/AUTEURS
+++ b/AUTEURS
@@ -541,7 +541,7 @@ Lars Hecking[e-mail beveiligd]>
Laszlo Molnar[e-mail beveiligd]>
Leif Huhn[e-mail beveiligd]>
Len Johnson[e-mail beveiligd]>
-Léon Brocard[e-mail beveiligd]>
+Oranje Brocard[e-mail beveiligd]>
Les Peters[e-mail beveiligd]>
Lesley Binks[e-mail beveiligd]>
Lincoln D.Stein[e-mail beveiligd]>

Voer uw wijziging nu lokaal door:

% git commit -a -m 'Hernoem Leon Brocard naar Orange Brocard'
Vastgelegde commit 6196c1d: Hernoem Leon Brocard naar Orange Brocard
1 bestanden gewijzigd, 1 invoegingen(+), 1 verwijderingen(-)

De "-a" optie wordt gebruikt om alle bestanden op te nemen die tracks bevatten die je hebt gewijzigd. Ik dik
deze keer wil je slechts enkele van de bestanden waaraan je hebt gewerkt vastleggen, je kunt de
"-a" en gebruik het commando "git add FILE ... " voordat u de commit uitvoert.
Met "git add --interactive" kun je zelfs maar delen van bestanden committen in plaats van allemaal
de veranderingen daarin.

De optie "-m" wordt gebruikt om het commit-bericht te specificeren. Als je het weglaat, zal git een
teksteditor waarmee u het bericht interactief kunt opstellen. Dit is handig als de wijzigingen
zijn complexer dan het hier gegeven voorbeeld, en, afhankelijk van de editor, om dat te weten
de eerste regel van het commit-bericht overschrijdt het wettelijke maximum van 50 tekens niet.

Zodra je klaar bent met het schrijven van je commit-bericht en je editor hebt verlaten, zal git schrijven
uw wijziging naar schijf en vertel u zoiets als dit:

Commit daf8e63 gemaakt: leg de git-status uit en zo over afstandsbedieningen
1 bestanden gewijzigd, 83 invoegingen(+), 3 verwijderingen(-)

Als je "git status" opnieuw uitvoert, zou je zoiets als dit moeten zien:

% git-status
# Op takbloeding
# Jouw branch ligt 2 commits voor op 'origin/blead'.
#
# Niet-bijgehouden bestanden:
# (gebruik "git add ..." om op te nemen in wat zal worden vastgelegd)
#
# opzettelijk.niet gevolgd
niets toegevoegd aan commit maar niet-bijgehouden bestanden aanwezig (gebruik "git add" om bij te houden)

Als u twijfelt, controleer dan eerst uw status en lees deze aandachtig door, voordat u iets anders doet
vragen worden direct beantwoord door de git statusuitvoer.

Je kunt je laatste commit bekijken met:

% git laat HOOFD zien

en als je niet tevreden bent met de beschrijving of de patch zelf, kun je deze repareren
door de bestanden nogmaals te bewerken en vervolgens het volgende uit te voeren:

% git commit -a --amend

Nu moet u een patchbestand maken voor al uw lokale wijzigingen:

% git format-patch -M blead..
0001-Hernoem-Leon-Brocard-naar-Oranje-Brocard.patch

Of voor veel wijzigingen, bijvoorbeeld vanuit een topic branch:

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

U dient nu een e-mail te sturen naar [e-mail beveiligd] <mailto:[e-mail beveiligd]> met een
beschrijving van uw wijzigingen en voeg dit patchbestand toe als bijlage. In aanvulling op
Omdat het wordt gevolgd door RT, wordt e-mail naar perlbug automatisch doorgestuurd naar perl5-porters
(met handmatige moderatie, dus wees geduldig). U dient alleen patches te sturen naar
[e-mail beveiligd] <mailto:[e-mail beveiligd]> direct als de patch nog niet gereed is
toegepast, maar bedoeld voor discussie.

Gelieve niet te gebruiken git-send-e-mail(1) om uw patch te verzenden. Zie Patch-e-mails verzenden voor meer informatie
informatie.

Als u uw tijdelijke vestiging wilt verwijderen, kunt u dat doen met:

% git kassa bleed
% git branch -d oranje
error: De tak 'oranje' is geen voorouder van je huidige HEAD.
Als je zeker weet dat je het wilt verwijderen, voer je 'git branch -D orange' uit.
% git branch -D oranje
Tak oranje verwijderd.

Het plegen jouw veranderingen
Ervan uitgaande dat je alle wijzigingen die je hebt aangebracht wilt vastleggen als een enkele atomaire eenheid,
voer deze opdracht uit:

% git commit -a

(Die "-a" vertelt git dat hij elk bestand dat je hebt gewijzigd aan deze commit moet toevoegen. Nieuwe bestanden niet
automatisch toegevoegd aan je commit als je "commit -a" gebruikt als je bestanden wilt toevoegen of aan
een paar, maar niet al je wijzigingen vastlegt, kijk eens naar de documentatie voor "git add".)

Git zal je favoriete teksteditor opstarten, zodat je een commit-bericht kunt maken
jouw verandering. Zie "Commit message" in perlhack voor meer informatie over wat een goed is
bericht vastleggen.

Zodra je klaar bent met het schrijven van je commit-bericht en je editor hebt verlaten, zal git schrijven
uw wijziging naar schijf en vertel u zoiets als dit:

Commit daf8e63 gemaakt: leg de git-status uit en zo over afstandsbedieningen
1 bestanden gewijzigd, 83 invoegingen(+), 3 verwijderingen(-)

Als je "git status" opnieuw uitvoert, zou je zoiets als dit moeten zien:

% git-status
# Op takbloeding
# Jouw branch ligt 2 commits voor op 'origin/blead'.
#
# Niet-bijgehouden bestanden:
# (gebruik "git add ..." om op te nemen in wat zal worden vastgelegd)
#
# opzettelijk.niet gevolgd
niets toegevoegd aan commit maar niet-bijgehouden bestanden aanwezig (gebruik "git add" om bij te houden)

Als u twijfelt, controleer dan eerst uw status en lees deze aandachtig door, voordat u iets anders doet
vragen worden direct beantwoord door de git statusuitvoer.

Verzending stuk e-mails
Nadat u uw patch heeft gegenereerd, moet u deze naar [e-mail beveiligd] (zoals besproken in
de vorige sectie) met een normale e-mailclient als bijlage, samen met een beschrijving
van de pleister.

Je Dan moet je niet . git-send-e-mail(1) om patches mee te verzenden die zijn gegenereerd git-formaat-patch(1). De
RT-ticketingsysteem leeft achter [e-mail beveiligd] respecteert de inline-inhoud van niet
E-mails, het verzenden van een inline patch naar RT garandeert dat uw patch zal worden vernietigd.

Iemand kan uw patch van RT downloaden, wat resulteert in het onderwerp (de eerste regel
van het commit-bericht) wordt weggelaten. Zie RT #74192 en commit a4583001 voor een voorbeeld.
Als alternatief kan iemand uw patch van RT toepassen nadat deze in zijn of haar mailbox is aangekomen
op welk tijdstip RT de inline-inhoud van het bericht zal hebben gewijzigd. Zie RT #74532 en
commit f9bcfeac voor een slecht voorbeeld van deze foutmodus.

A nota on afgeleide bestanden
Houd er rekening mee dat veel bestanden in de distributie afgeleide bestanden zijn; vermijd het patchen ervan, omdat
git zal de wijzigingen daarin niet zien, en het bouwproces zal ze overschrijven. Patch de
originelen in plaats daarvan. De meeste hulpprogramma's (zoals perldoc) vallen in deze categorie, dwz patch
utils/perldoc.PL dan utils/perldoc. Maak ook geen patches voor bestanden
onder $src_root/ext van hun kopieën gevonden in $install_root/lib. Als u er niet zeker van bent
de juiste locatie van een bestand dat mogelijk is gekopieerd tijdens het bouwen van de broncode
distributie, raadpleeg het "MANIFEST".

Reiniging a werkzaam directory
Het commando "git clean" kan met verschillende argumenten gebruikt worden als vervanging voor "make
schoon".

Om uw werkmap terug te zetten naar een onberispelijke staat, kunt u het volgende doen:

% git schoon -dxf

Houd er echter rekening mee dat hierdoor ALLE niet-bijgehouden inhoud wordt verwijderd. Je kunt gebruiken

% git schoon -Xf

om alle genegeerde niet-bijgehouden bestanden te verwijderen, zoals build- en test-bijproduct, maar laat ze staan
alleen handmatig gemaakte bestanden.

Als je alleen enkele niet-vastgelegde bewerkingen wilt annuleren, kun je "git checkout" gebruiken en dit doorgeven
een lijst met bestanden die teruggezet moeten worden, of "git checkout -f" om ze allemaal terug te zetten.

Als je één of meerdere commits wilt annuleren, kun je "git reset" gebruiken.

in tweeën delen
"git" biedt een ingebouwde manier om te bepalen welke commit de schuld moet krijgen voor het introduceren van een
gegeven bug. "git bisect" voert een binaire zoektocht in de geschiedenis uit om de eerste fout te lokaliseren
verbinden. Het is snel, krachtig en flexibel, maar vereist enige installatie en automatisering
proces is een hulpshellscript nodig.

De kern biedt een wrapperprogramma, Porting/bisect.pl, die probeert zoveel mogelijk te vereenvoudigen
mogelijk te maken, waardoor het in tweeën delen net zo eenvoudig wordt als het uitvoeren van een Perl-oneliner. Als u bijvoorbeeld
wil weten wanneer dit een fout werd:

perl -e 'mijn $a := 2'

je voert eenvoudig dit uit:

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

Met behulp van "bisect.pl", met één commando (en geen andere bestanden), is het gemakkelijk om erachter te komen

· Welke commit zorgde ervoor dat deze voorbeeldcode kapot ging?

· Welke commit zorgde ervoor dat deze voorbeeldcode begon te werken?

· Welke commit heeft het eerste bestand toegevoegd dat overeenkomt met deze regex?

· Welke commit heeft het laatste bestand verwijderd dat overeenkomt met deze regex?

meestal zonder dat u hoeft te weten welke versies van perl u als begin- en eindrevisie moet gebruiken,
as halveren.pl zoekt automatisch naar de vroegste stabiele versie waarvoor de test is uitgevoerd
zaak gaat voorbij. Voer "Porting/bisect.pl --help" uit voor de volledige documentatie, inclusief instructies
stel de opties "Configureren" en bouwtijd in.

Als u meer flexibiliteit nodig heeft dan Porting/bisect.pl te bieden heeft, zul je moeten vluchten
"git halveer" jezelf. Het is het handigst om "git bisect run" te gebruiken om het gebouw te automatiseren
en testen van perl-revisies. Hiervoor heb je een shellscript nodig waar "git" naartoe kan bellen
een bepaalde revisie testen. Een voorbeeldscript is Porting/doorsnijden-voorbeeld.sh, die jij
zou moeten kopiëren buiten van de repository, omdat het bisect-proces de status zal resetten naar a
schoon afrekenen terwijl het loopt. Bij de onderstaande instructies wordt ervan uitgegaan dat u het hebt gekopieerd als ~/rennen en
en vervolgens indien nodig bewerkt.

Je komt eerst in de bisect-modus met:

% git halveert start

Als de bug bijvoorbeeld aanwezig is op "HEAD" maar niet in 5.10.0, zal "git" meer te weten komen over
dit als je binnenkomt:

% git halveert slecht
% git deelt goede perl-5.10.0 in tweeën
In tweeën gedeeld: hierna zijn er nog 853 revisies om te testen

Dit resulteert in het controleren van de gemiddelde commit tussen "HEAD" en "perl-5.10.0". Jij kan
voer vervolgens het halveringsproces uit met:

% git bisect uitgevoerd ~/rennen

Wanneer de eerste slechte commit wordt geïsoleerd, zal "git bisect" je dat vertellen:

ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 is first bad commit
commit ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5
Auteur: Dave Mitchell[e-mail beveiligd]>
Datum: za 9 februari 14:56:23 2008 +0000

[perl #49472] Kenmerken + onbekende fout
...

succes in tweeën delen

Je kunt een kijkje nemen in het bisecteerproces met "git bisect log" en "git bisect visualiseren".
"git bisect reset" haalt je uit de bisect-modus.

Houd er rekening mee dat de eerste "goede" toestand een voorloper moet zijn van de eerste "slechte" toestand. Als
je wilt zoeken naar de commit die opgelost een bug, je moet je testcase tenietdoen
(dwz sluit af met 1 als dit OK is en 0 als dat niet het geval is) en markeer nog steeds de ondergrens als "goed" en de
bovenste als "slecht". De "eerste slechte commit" moet dan worden opgevat als de "eerste commit".
waar de fout is opgelost".

"git help bisect" heeft veel meer informatie over hoe je je binaire zoekopdrachten kunt aanpassen.

Thema takken en herschrijven geschiedenis
Individuele committers moeten onderwerpvertakkingen maken onder uw naam/een_beschrijvende_naam.
Andere committers moeten contact opnemen met de maker van een topic branch voordat ze er enige wijziging in aanbrengen
het.

De eenvoudigste manier om een ​​remote topic branch te maken die op alle versies van git werkt, is door
duw de huidige kop als een nieuwe branch op de afstandsbediening en bekijk deze vervolgens lokaal:

$ branch="$uwnaam/$een_beschrijvende_naam"
$ git push oorsprong HEAD:$branch
$git checkout -b $branch origin/$branch

Gebruikers van git 1.7 of nieuwer kunnen het op een meer voor de hand liggende manier doen:

$ branch="$uwnaam/$een_beschrijvende_naam"
$git checkout -b $branch
$ git push origin -u $branch

Als u niet de maker bent van uw naam/een_beschrijvende_naam, zul je soms tegenkomen
dat de oorspronkelijke auteur de geschiedenis van het filiaal heeft bewerkt. Er zijn veel goede redenen
voor deze. Soms kan een auteur de branch simpelweg opnieuw baseren op een nieuwere bron
punt. Soms heeft een auteur een fout gevonden in een vroege commit die hij of zij heeft uitgevoerd
wilde repareren voordat ik de tak samenvoegde om te ontluchten.

Momenteel is de masterrepository geconfigureerd om niet-snel vooruit samenvoegen te verbieden. Dit
betekent dat de vertakkingen binnenin niet als één enkele stap opnieuw kunnen worden gebaseerd en gepusht.

De enige manier waarop je ooit de geschiedenis van een gepushte branch kunt rebasen of wijzigen
is om het te verwijderen en het als een nieuwe branch onder dezelfde naam te pushen. Denk alstublieft goed na
over dit doen. Het kan beter zijn om uw branches opeenvolgend te hernoemen, zodat dit zo is
gemakkelijker voor anderen die met u samenwerken om hun lokale wijzigingen naar de nieuwe te kiezen
versie. (XXX: heeft uitleg nodig).

Als u een persoonlijke onderwerptak wilt rebasen, moet u uw bestaande onderwerp verwijderen
branch en push als een nieuwe versie ervan. Dit kunt u doen via de volgende formule (zie de
uitleg over "refspec"'s in de git push documentatie voor details) nadat je dat hebt gedaan
uw branch opnieuw gebaseerd:

# eerste rebase
$ git checkout $user/$topic
$ git ophalen
$ git rebase oorsprong/blead

# en vervolgens "verwijderen en duwen"
$ git push oorsprong:$user/$topic
$ git push oorsprong $user/$topic

NOTITIE: het is op repositoryniveau verboden om een ​​van de "primaire" takken te verwijderen.
Dat is elke branch die overeenkomt met "m!^(blead|maint|perl)!". Elke poging hiertoe zal resulteren in
git produceert een fout als deze:

$ git push oorsprong:blead
*** Het is verboden om blead/maint-takken in deze repository te verwijderen
fout: hooks/update afgesloten met foutcode 1
fout: hook weigerde refs/heads/blead bij te werken
Naar ssh://perl5.git.perl.org/perl
! [op afstand afgewezen] bloeding (haak geweigerd)
fout: het lukte niet om enkele referenties naar 'ssh://perl5.git.perl.org/perl' te pushen

Als beleidskwestie doen we dat wel niet bewerk de geschiedenis van de blead- en maint-*-takken. Als een
typfout (of erger) sluipt in een commit om te blead of maint-*, we zullen het in een andere commit repareren.
De enige soorten updates die op deze branches zijn toegestaan, zijn "fast-forward's", waar alles
geschiedenis blijft bewaard.

Geannoteerde tags in de canonieke perl.git-repository zullen nooit worden verwijderd of gewijzigd.
Denk er lang over na of je een lokale tag naar perl.git wilt pushen voordat je dat doet
Dus. (Het pushen van niet-geannoteerde tags is niet toegestaan.)

Transplantaten
De perl-geschiedenis bevat één fout die niet werd opgemerkt bij de conversie: er was sprake van een merge
opgenomen in de geschiedenis tussen blead en maint-5.10, waar feitelijk geen samenvoeging heeft plaatsgevonden. Vanwege
door de aard van git is dit nu onmogelijk op te lossen in de openbare repository. Jij kan
verwijder deze foutieve samenvoeging lokaal door de volgende regel toe te voegen aan uw ".git/info/grafts"
file:

296f12bbbbaa06de9be9d09d3dcf8f4528898a49 434946e0cb7a32589ed92d18008aaa1d88515930

Het is vooral belangrijk om deze transplantaatlijn te hebben als er in het gebied een doorsnijding wordt uitgevoerd
van de "fusie" in kwestie.

SCHRIJVEN TOEGANG TO HET GIT OPSLAGPLAATS

Zodra u schrijftoegang heeft, moet u de URL voor de oorspronkelijke afstandsbediening wijzigen
duwen mogelijk maken. Bewerking .git/config met de git-config(1) commando:

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

U kunt ook uw gebruikersnaam en e-mailadres instellen. De meeste mensen doen dit wereldwijd een keer
in de ~ / .gitconfig door iets te doen als:

% git config --global user.name "AEvar Arnfjoer` Bjarmason"
% git config --global user.email [e-mail beveiligd]

Als u dat echter alleen voor perl wilt overschrijven, voert u zoiets uit als
volgen in perl:

% git config gebruiker.email [e-mail beveiligd]

Het is ook mogelijk om "origin" als een git remote te behouden, en een nieuwe remote toe te voegen voor ssh-toegang:

% git op afstand voeg camel toe perl5.git.perl.org:/perl.git

Hierdoor kunt u uw lokale repository bijwerken door vanuit "origin" te halen, wat sneller is
en vereist niet dat u zich authenticeert en uw wijzigingen terugstuurt met de "kameel"
afstandsbediening:

% git fetch kameel
% git push kameel

Het commando "fetch" werkt alleen de referenties van "camel" bij, zoals de objecten zelf zouden moeten hebben
opgehaald bij het ophalen van "origin".

Het accepteren van a stuk
Als u een patchbestand hebt ontvangen dat is gegenereerd met behulp van de bovenstaande sectie, moet u het uitproberen
de pleister.

Eerst moeten we een tijdelijke nieuwe branch maken voor deze wijzigingen en ernaar overschakelen:

% git checkout -b experimenteel

Patches die zijn geformatteerd met "git format-patch" worden toegepast met "git am":

% git am 0001-Hernoem-Leon-Brocard-naar-Orange-Brocard.patch
Hernoemen van Leon Brocard naar Orange Brocard toepassen

Als er alleen een onbewerkt diff wordt opgegeven, is het ook mogelijk dit tweestapsproces te gebruiken:

% git past bugfix.diff toe
% git commit -a -m "Een oplossing" --author="Die kerel[e-mail beveiligd]>"

Nu kunnen we de verandering inspecteren:

% git laat HOOFD zien
commit b1b3dab48344cff6de4087efca3dbd63548ab5e2
Auteur: Leon Brocard[e-mail beveiligd]>
Datum: vrijdag 19 december 17:02:59 2008 +0000

Hernoem Leon Brocard naar Orange Brocard

diff --git a/AUTEURS b/AUTEURS
index 293dd70..722c93e 100644
--- a/AUTEURS
+++ b/AUTEURS
@@ -541,7 +541,7 @@ Lars Hecking[e-mail beveiligd]>
Laszlo Molnar[e-mail beveiligd]>
Leif Huhn[e-mail beveiligd]>
Len Johnson[e-mail beveiligd]>
-Léon Brocard[e-mail beveiligd]>
+Oranje Brocard[e-mail beveiligd]>
Les Peters[e-mail beveiligd]>
Lesley Binks[e-mail beveiligd]>
Lincoln D.Stein[e-mail beveiligd]>

Als u een committer bent van Perl en u denkt dat de patch goed is, kunt u deze vervolgens samenvoegen
blead en duw het vervolgens naar de hoofdrepository:

% git kassa bleed
% git merge experimenteel
% git push oorsprong blead

Als u uw tijdelijke vestiging wilt verwijderen, kunt u dat doen met:

% git kassa bleed
% git branch -d experimenteel
error: De tak 'experimenteel' is geen voorloper van je huidige HEAD.
Als je zeker weet dat je het wilt verwijderen, voer dan 'git branch -D experimenteel' uit.
% git branch -D experimenteel
Experimenteel vertakking verwijderd.

Het plegen naar bloeden
De 'blead'-tak wordt de volgende productieversie van Perl.

Voordat je gaat duwen elke lokale verandering om te bloeden, het is ongelooflijk belangrijk dat u er een paar doet
dingen, opdat andere daders niet achter je aan komen met hooivorken en fakkels:

· Zorg ervoor dat je een goede commit-boodschap hebt. Zie "Commit message" in perlhack voor
details.

· Voer het testpakket uit. Je denkt misschien niet dat één typfout een testbestand kapot zou maken.
Je zou het mis hebben. Hier is een voorbeeld waarbij het niet uitvoeren van de suite problemen veroorzaakte. A
Er werd een patch ingediend die een aantal tests toevoegde aan een bestaande .t. Dat kon niet
mogelijk van invloed op iets anders, dus het is niet nodig om verder te testen dan de enkele getroffen .t,
rechts? Maar het e-mailadres van de indiener was veranderd sinds de laatste van hun
inzendingen, en dit zorgde ervoor dat andere tests mislukten. Het uitvoeren van het testdoel dat is opgegeven in de
het volgende item zou dit probleem hebben opgelost.

· Als u niet het volledige testpakket uitvoert, moet u op zijn minst "make test_porting" gebruiken. Dit zal lopen
basisgezondheidscontroles. Kijk eens in om te zien welke sanity checks er zijn t/porteren.

· Als u wijzigingen aanbrengt die van invloed zijn op miniperl of kernroutines met andere code
paden voor miniperl, zorg ervoor dat u "make minitest" uitvoert. Dit zal problemen opleveren
zelfs de volledige testsuite zal niet aanslaan omdat er een subset van tests onder wordt uitgevoerd
miniperl in plaats van perl.

On samen te voegen en rebasen
Eenvoudige, eenmalige commits die naar de 'blead'-branch worden gepusht, moeten eenvoudige commits zijn die van toepassing zijn
schoon. Met andere woorden, u moet ervoor zorgen dat uw werk tegen de stroom in wordt gepleegd
positie van blead, zodat u terug kunt gaan naar de hoofdrepository zonder samen te voegen.

Soms beweegt het bloed terwijl u uw wijzigingen aan het bouwen of testen bent. Wanneer dit
gebeurt, wordt uw push afgewezen met een bericht als dit:

Naar ssh://perl5.git.perl.org/perl.git
! [afgewezen] blead -> blead (niet vooruitspoelen)
fout: het lukte niet om enkele refs naar 'ssh://perl5.git.perl.org/perl.git' te pushen
Om te voorkomen dat u de geschiedenis verliest, zijn niet-snel vooruitspoelende updates afgewezen
Voeg de wijzigingen op afstand samen (bijvoorbeeld 'git pull') voordat je opnieuw pusht. Zie de
'Opmerking over snel vooruitspoelen' sectie van 'git push --help' voor details.

Wanneer dit gebeurt, kunt u gewoon opnieuw baseren jouw werk tegen de nieuwe positie van blead, zoals
dit (ervan uitgaande dat uw afstandsbediening voor de hoofdrepository "p5p" is):

$ git haal p5p op
$git rebase p5p/blead

Je zult zien dat je commits opnieuw worden toegepast, en je zult dan veilig kunnen pushen.
Meer informatie over rebasen vindt u in de documentatie voor de git-rebase(1)
opdracht.

Voor grotere sets commits die alleen samen zinvol zijn, of die baat zouden hebben bij een
samenvatting van het doel van de set, zou je een merge commit moeten gebruiken. Je moet je werk uitvoeren
op een topic branch, die je regelmatig moet rebasen tegen blead om ervoor te zorgen dat je
code wordt niet verbroken door het verplaatsen van de bloeding. Als u klaar bent met uw werk, voer dan een
laatste rebase en test. Lineaire geschiedenis is iets dat bij elke commit verloren gaat
bloeden, maar een laatste rebase maakt de geschiedenis weer lineair, waardoor het gemakkelijker wordt voor de toekomst
beheerders om te zien wat er is gebeurd. Rebase als volgt (ervan uitgaande dat uw werk zich op de
branch "committer/somework"):

$ git checkout committer/somework
$ git rebase blead

Vervolgens kunt u het als volgt in de master samenvoegen:

$ git kassa blead
$ git merge --no-ff --no-commit committer/somework
$ git vastleggen -a

De bovenstaande schakelaars verdienen uitleg. "--no-ff" geeft aan dat zelfs als al uw werk
kan lineair worden toegepast tegen blead, er moet nog steeds een merge commit worden voorbereid. Dit
zorgt ervoor dat al je werk wordt getoond als een zijtak, met alle commits samengevoegd
door de fusiecommit in de mainstream terechtkomen.

"--no-commit" betekent dat de merge commit zal plaatsvinden bereid maar niet toegewijd. De verplichting
wordt dan daadwerkelijk uitgevoerd wanneer u de volgende opdracht uitvoert, waardoor uw editor wordt geopend
om de verbintenis te beschrijven. Zonder "--no-commit" zou de commit gedaan worden met bijna geen
nuttige boodschap, die de waarde van de merge commit als
tijdelijke aanduiding voor de beschrijving van het werk.

Wanneer je de merge commit beschrijft, leg dan het doel van de branch uit, en houd dat in gedachten
deze beschrijving zal waarschijnlijk door de uiteindelijke release engineer worden gebruikt bij het beoordelen van de
volgende perldelta-document.

Het plegen naar onderhoud versies
Onderhoudsversies mogen alleen worden gewijzigd om kritieke bugfixes toe te voegen, zie perlpolicy.

Om een ​​onderhoudsversie van perl vast te leggen, moet u een lokale trackingbranch aanmaken:

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

Hierdoor wordt een lokale vertakking gemaakt met de naam "maint-5.005", die de externe vertakking volgt
"oorsprong/onderhoud-5.005". Vervolgens kunt u zoals voorheen pullen, committen, mergen en pushen.

Je kunt ook commits van blead en een andere branch uitkiezen, door het bestand "git
cherry-pick" commando. Het wordt aanbevolen om de -x optie om "git cherry-pick" op volgorde te zetten
om de SHA1 van de originele commit in het nieuwe commit-bericht op te nemen.

Voordat u een wijziging naar een hoofdversie doorvoert, moet u ervoor zorgen dat u aan de stappen in
"Toewijden aan bloeden" hierboven.

Samenvoegen van a tak via GitHub
Hoewel we het indienen van patches via GitHub niet aanmoedigen, zal dat nog steeds gebeuren.
Hier is een handleiding voor het samenvoegen van patches uit een GitHub-repository.

% git remote voeg avar toe git://github.com/avar/perl.git
% git haalt avar op

Nu kun je de verschillen zien tussen de tak en de bloeding:

% git diff avar/oranje

En je kunt de commits zien:

% git log avar/oranje

Als je een specifieke commit goedkeurt, kun je deze kiezen:

% git cherry-pick 0c24b290ae02b2ab3304f51d5e11e85eb3659eae

Of je kunt gewoon de hele branch samenvoegen als je het allemaal leuk vindt:

% git merge avar/oranje

En duw dan terug naar de repository:

% git push oorsprong blead

gebruik a rook me tak naar proef veranderingen
Soms heeft een wijziging invloed op codepaden die u niet kunt testen op de besturingssystemen die dat wel zijn
voor u beschikbaar en het zou verstandig zijn om gebruikers van andere besturingssystemen de wijziging eerder te laten testen
je laat het bloeden.

Gelukkig is er een manier om uw wijziging op verschillende besturingssystemen aan een rooktest te laten onderwerpen: push it to a
"smoke-me" -tak en wacht tot bepaalde geautomatiseerde rooktesters de resultaten rapporteren
hun besturingssystemen.

De procedure hiervoor is grofweg als volgt (aan de hand van het voorbeeld van Tonyc's rook-
me branch genaamd win32stat):

Maak eerst een lokale branch en schakel ernaar over:

% git checkout -b win32stat

Breng enkele wijzigingen aan, bouw perl en test uw wijzigingen, en voer ze vervolgens door naar uw lokale
tak. Duw vervolgens uw lokale vestiging naar een externe smoke-me-vestiging:

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

Nu kunt u lokaal terugschakelen naar bloeden:

% git kassa bleed

en blijf aan andere dingen werken terwijl je een dag of twee wacht, terwijl je de
resultaten gerapporteerd voor uw smoke-me-filiaal op
<http://perl.develop-help.com/?b=smoke-me/tonyc/win32state>.

Als alles goed is, update dan je blead-tak:

% git-pull

bekijk dan nogmaals je smoke-me-tak en rebase deze op blead:

% git rebase bleek win32stat

Schakel nu terug naar Blead en voeg je Smoke-Me-tak erin samen:

% git kassa bleed
% git merge win32stat

Zoals eerder beschreven, als er veel veranderingen zijn in uw smoke-me-tak, zou u dat moeten doen
bereid een merge commit voor waarin je een overzicht geeft van die wijzigingen door gebruik te maken van de
volgende opdracht in plaats van de laatste opdracht hierboven:

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

U moet nu perl bouwen en uw (samengevoegde) wijzigingen nog een laatste keer testen (bij voorkeur voer de
hele testsuite, maar als dat niet lukt, voer dan in ieder geval de t/porteren/*.t testen) voordat u gaat duwen
uw wijzigingen zoals gewoonlijk:

% git push oorsprong blead

Ten slotte moet u vervolgens de externe smoke-me-tak verwijderen:

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

(wat waarschijnlijk een waarschuwing als deze zal opleveren, die genegeerd kan worden:

op afstand: fataal: dubbelzinnig argument 'refs/heads/smoke-me/tonyc/win32stat':
onbekende revisie of pad niet in de werkende boom.
extern: gebruik '--' om paden van revisies te scheiden

) en verwijder vervolgens uw lokale branch:

% git branch -d win32stat

A nota on kameel en dromedaris
De committers hebben SSH-toegang tot de twee servers die "perl5.git.perl.org" bedienen. Een is
"perl5.git.perl.org" zelf (kameel), wat de 'master'-repository is. De tweede is
"gebruikers.perl5.git.perl.org" (dromedaris), die kan worden gebruikt voor algemene tests en
ontwikkeling. Dromedary synchroniseert de git tree van camel elke paar minuten, dat zou je niet moeten doen
daar duwen. Beide machines hebben ook een volledige CPAN-mirror in /srv/CPAN, gebruik deze alstublieft. Naar
deel bestanden met het grote publiek, dromedaris bedient uw ~/openbare_html/ as
"http://users.perl5.git.perl.org/~yourlogin/"

Deze hosts hebben vrij strikte firewalls naar buiten toe. Uitgaand, alleen rsync, ssh en git
zijn toegestaan. Voor http en ftp kunt u gebruik maken van http://webproxy:3128 als proxy. Inkomend, de
firewall probeert aanvallen te detecteren en blokkeert IP-adressen met verdachte activiteit. Dit
soms (maar zeer zelden) heeft u valse positieven en wordt u mogelijk geblokkeerd. De snelste
De manier om de blokkering op te heffen is door de beheerders op de hoogte te stellen.

Deze twee boxen zijn eigendom van, worden gehost en beheerd door booking.com. U kunt de
sysadmins in #p5p op irc.perl.org of via mail naar "[e-mail beveiligd]".

Gebruik perlgit online met behulp van onworks.net-services