Git
Chapters ▾ 2nd Edition

6.2 GitHub - Prispevek k projektu

Prispevek k projektu

Sedaj, ko je vaš račun nastavljen, pojdimo skozi nekaj podrobnosti, ki bi vam bile lahko koristile pri prispevku k obstoječemu projektu.

Vejitev projektov

Če želite prispevati obstoječemu projektu, do katerega nimate pravic potiskanja, lahko naredite »vejitev« (angl. fork) projekta. Ko razvejite projekt, bo GitHub naredil kopijo projekta, ki ni v celoti vaša; obstoji v vašem imenskem prostoru in nanj lahko potiskate.

Opomba

Zgodovinski izraz za vejitev je bil nekoliko negativen v kontekstu, kar pomeni, da je nekdo usmeril odprtokodni projekt v drugačno smer in včasih ustvaril konkurenčni projekt ter razdvojil ljudi, ki so prispevali. Na GitHubu je »vejitev« enostavno isti projekt v vašem imenskem prostoru, kar vam omogoča, da javno naredite spremembe k projektu kot način prispevka na bolj odprti način.

V tem primeru projektom ni treba skrbeti za dodajanje uporabnikov kot sodelavcev, da se jim da dostop potiskanja. Ljudje lahko vejijo projekt, vanj potiskajo in prispevajo svoje spremembe nazaj v originalni repozitorij z ustvarjanjem zahtevka potega, ki ga bomo pokrili v nadaljevanju. To odpre temo diskusije s pregledom kode in lastnik ter sodelujoči lahko komunicirata o spremembi, dokler lastnik ni z njo zadovoljen ter jo nato lahko združi v projekt.

Da vejite projekt, obiščite spletno stran projekta in kliknite na gumb »Fork« na zgornji desni strani.

Gumb »Fork«
Slika 88. Gumb »Fork«

Po nekaj sekundah boste pripeljani na novo stran projekta s svojo lastno kopijo kode.

Potek GitHub

GitHub je zasnovan okoli posebnega načina sodelovanja, osredotočenega na zahtevke potegov (angl. pull requests). Ta način delovanja deluje, bodisi če sodelujete z močno povezano ekipo v enem skupnem repozitoriju ali pa z globalno razpršenim podjetjem ali omrežjem tujcev, ki prispevajo k projektu prek desetin razvejitev. Osredotočen je na potek dela Tematske veje, ki je predstavljen v Veje Git.

Takole deluje na splošno:

  1. Razvejite projekt.

  2. Ustvarite tematsko vejo iz veje master.

  3. Naredite nekaj potrditev za izboljšanje projekta.

  4. To vejo potisnite v svoj projekt GitHub.

  5. Odprite zahtevek potega na GitHubu.

  6. Razpravljajte in po potrebi še naprej delajte potrditve.

  7. Lastnik projekta združi ali zapre zahtevek potega.

  8. Sinhronizirajte posodobljeni master nazaj v svojo razvejitev.

To je v bistvu potek dela upravitelja integracije, ki je predstavljen v Potek dela s povezovalnim upraviteljem, vendar namesto uporabe elektronske pošte za komuniciranje in pregledovanje sprememb, ekipe uporabljajo orodja na spletnem mestu GitHub.

Pojdimo skozi primer predlaganja spremembe v projektu odprte kode, gostujočem na GitHubu, s pomočjo tega poteka.

Namig

Namesto spletnega vmesnika GitHub lahko za večino stvari uporabite uradno orodje GitHub CLI. Orodje lahko uporabljate na sistemih Windows, macOS in Linux. Za navodila za namestitev in priročnik obiščite domačo stran GitHub CLI.

Ustvarjanje zahtevka potega

Tony išče kodo, ki bi jo lahko izvajal na svojem programabilnem mikrokrmilniku Arduino, in je našel odlično programsko datoteko na GitHubu na https://github.com/schacon/blink.

Projekt, ki mu želimo prispevati
Slika 89. Projekt, ki mu želimo prispevati

Edini problem je, da je utripanje prehitro. Menimo, da je veliko lepše počakati 3 sekunde namesto 1 med vsako spremembo stanja. Torej izboljšajmo program in ga predložimo nazaj v projekt kot predlagano spremembo.

Najprej kliknemo gumb »Fork«, kot je že omenjeno, da dobimo lastno kopijo projekta. Naše uporabniško ime tukaj je »tonychacon«, torej je naša kopija tega projekta na https://github.com/tonychacon/blink, kjer ga lahko urejamo. Lokalno ga bomo klonirali, ustvarili tematsko vejo, naredili spremembo v kodi in nazadnje to spremembo potisnili nazaj na GitHub.

$ git clone https://github.com/tonychacon/blink (1)
Cloning into 'blink'...

$ cd blink
$ git checkout -b slow-blink (2)
Switched to a new branch 'slow-blink'

$ sed -i '' 's/1000/3000/' blink.ino (macOS) (3)
# If you're on a Linux system, do this instead:
# $ sed -i 's/1000/3000/' blink.ino (3)

$ git diff --word-diff (4)
diff --git a/blink.ino b/blink.ino
index 15b9911..a6cc5a5 100644
--- a/blink.ino
+++ b/blink.ino
@@ -18,7 +18,7 @@ void setup() {
// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  [-delay(1000);-]{+delay(3000);+}               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  [-delay(1000);-]{+delay(3000);+}               // wait for a second
}

$ git commit -a -m 'Change delay to 3 seconds' (5)
[slow-blink 5ca509d] Change delay to 3 seconds
 1 file changed, 2 insertions(+), 2 deletions(-)

$ git push origin slow-blink (6)
Username for 'https://github.com': tonychacon
Password for 'https://tonychacon@github.com':
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/tonychacon/blink
 * [new branch]      slow-blink -> slow-blink
  1. Klonirajte svojo razvejitev projekta lokalno.

  2. Ustvarite opisno tematsko vejo.

  3. Naredite spremembo v kodi.

  4. Preverite, da je sprememba dobra.

  5. Potrdite spremembo v tematski veji.

  6. Potisnite novo tematsko vejo nazaj v svojo razvejitev GitHub.

Če se vrnemo na svojo razvejitev projekta na GitHubu, lahko vidimo, da je GitHub opazil, da smo potisnili novo tematsko vejo in nam predstavi velik zelen gumb, s katerim lahko preverimo svoje spremembe in odpremo zahtevek potega na originalni projekt.

Namesto tega lahko greste na stran »Branches« na https://github.com/<user>/<project>/branches, da najdete svojo vejo, in od tam odprete nov zahtevek potega.

Gumb za zahtevek potega
Slika 90. Gumb za zahtevek potega

Če kliknemo ta zeleni gumb, bomo videli zaslon, ki nas prosi, da dodelimo svojemu zahtevku potega naslov in opis. Skoraj vedno se splača v to vložiti nekaj truda, saj dober opis pomaga lastniku originalnega projekta ugotoviti, kaj ste poskušali storiti, ali so vaše predlagane spremembe pravilne in ali bi sprejetje sprememb izboljšalo izvirni projekt.

Prav tako vidimo seznam potrditev v svoji tematski veji, ki so »naprej« od glavne veje master (v tem primeru samo ena) in združeno razliko vseh sprememb, ki bodo narejene, če bo ta veja združena s strani lastnika projekta.

Stran za ustvarjanje zahtevka potega
Slika 91. Stran za ustvarjanje zahtevka potega

Ko pritisnete gumb »Create pull request« na tej strani, bo lastnik projekta, ki ste ga razvejali, prejel obvestilo, da nekdo predlaga spremembo in bo dobil povezavo do strani, ki vsebuje vse te informacije.

Opomba

Čeprav se zahtevki potega pogosto uporabljajo za javne projekte, kot je ta, ko ima sodelujoči pripravljeno celotno spremembo, se pogosto uporablja tudi v notranjih projektih na začetku razvojnega cikla. Ker lahko v tematsko vejo še naprej potiskate tudi po odprtju zahtevka potega, se ta pogosto odpre zgodaj in uporablja kot način iteracije dela kot skupine znotraj konteksta, namesto da se odpre na koncu postopka.

Iteracija na zahtevku potega

V tem trenutku lahko lastnik projekta pregleda predlagano spremembo in jo združi, zavrne, ali nanjo komentira. Recimo, da mu je ideja všeč, vendar bi raje imel malo daljši čas za izklop kot vklop luči.

Medtem ko se lahko ta pogovor odvija preko e-pošte v potekih dela, predstavljenih v poglavju Porazdeljeni Git, se na GitHubu to zgodi na spletu. Lastnik projekta lahko pregleda združeno razliko (angl. diff) in pusti komentar, tako da klikne na katero koli od vrstic.

Komentar na določeni vrstici kode v zahtevku potega
Slika 92. Komentar na določeni vrstici kode v zahtevku potega

Ko vzdrževalec napiše ta komentar, bo oseba, ki je odprla zahtevek potega (in vsakdo drug, ki spremlja ta repozitorij), prejela obvestilo. Kasneje bomo opisali, kako lahko prilagodite ta obvestila, vendar če ima Tony vklopljena obvestila po e-pošti, bi prejel e-poštno sporočilo takole:

Komentarji poslani kot e-poštna obvestila
Slika 93. Komentarji poslani kot e-poštna obvestila

Kdor koli lahko tudi pusti splošne komentarje na zahtevku potega. Na sliki Stran za diskusijo zahtevka potega lahko vidimo primer, ko lastnik projekta komentira vrstico kode in nato pusti splošen komentar v razdelku za razpravo. Vidite lahko, da so komentarji kode prav tako vključeni v pogovor.

Stran za diskusijo zahtevka potega
Slika 94. Stran za diskusijo zahtevka potega

Sedaj lahko sodelujoči vidi, kaj mora storiti, da bo njegova sprememba sprejeta. Na srečo je to zelo preprosto. Kjer bi morali preko e-pošte ponovno uvrstiti svojo serijo in jo ponovno poslati na seznam za pošiljanje, lahko preko GitHuba preprosto spet potrdite na svoji tematski veji in jo potisnete, kar bo samodejno posodobilo zahtevek potega. Na sliki Končni zahtevek potega lahko vidite tudi, da je bil star komentar kode zložen v posodobljenem zahtevku potega, saj je bil narejen na vrstici, ki je bila od takrat spremenjena.

Dodajanje potrditev k obstoječemu zahtevku potega ne sproži obvestila, zato se Tony odloči, da bo pustil komentar, da obvesti lastnika projekta, da je izvedel zahtevano spremembo.

Končni zahtevek potega
Slika 95. Končni zahtevek potega

Zanimivo je opaziti, da če kliknete na zavihek »Files Changed« na tem zahtevku potega, boste dobili »združeno« razliko — torej skupno razliko, ki bi jo v glavno vejo uvedli, če bi bila ta tematska veja združena. V pojmu git diff vam to v bistvu avtomatično prikaže git diff master…​<branch> za vejo, na kateri temelji ta zahtevek potega. Za več informacij o tej vrsti razlike si oglejte razdelek Določanje, kaj se uvaja.

Druga stvar, ki jo boste opazili, je, da GitHub preveri, ali se zahtevek potega združi brez težav, in ponudi gumb za izvedbo združevanja na strežniku. Ta gumb se prikaže le, če imate dostop za pisanje v repozitoriju in če je mogoča trivialna združitev. Če nanj kliknete, bo GitHub izvedel združitev »non-fast-forward«, kar pomeni, da bo ustvaril potrditev združitve, tudi če bi lahko združitev bila hitro previta naprej.

Če želite, lahko preprosto povlečete vejo navzdol in jo lokalno združite. Če to vejo združite v vejo master in jo potisnete na GitHub, bo zahtevek potega samodejno zaprt.

To je osnovni potek dela, ki ga uporablja večina projektov na GitHubu. Ustvarijo se tematske veje, nanje se odprejo zahtevki potegov, sledi razprava, morda se na veji opravi še več dela, dokler zahtevek ni zaprt ali združen.

Opomba
Ne samo razvejitve

Pomembno je omeniti, da lahko odprete zahtevek potega med dvema vejama v istem repozitoriju. Če delate z nekom na določeni funkciji in imata oba dostop zapisovanja v projekt, lahko potisnete tematsko vejo v repozitorij in odprete zahtevek potega na vejo master tega projekta, da sprožite postopek pregleda kode in razprave. Ni potrebe po ustvarjanju razvejitve projekta.

Napredni zahtevki potegov

Zdaj, ko smo pokrili osnove sodelovanja v projektu na GitHubu, si oglejmo nekaj zanimivih nasvetov in trikov o zahtevkih potegov, tako da boste lahko bolj učinkovito uporabljali to funkcionalnost.

Zahtevki potegov kot popravki

Pomembno je razumeti, da se mnogi projekti ne osredotočajo na zahtevke potegov kot vrste popolnih popravkov, ki se lahko uporabijo brezhibno po vrstnem redu, kot to velja za projekte, ki temeljijo na elektronski pošti. Večina projektov na GitHubu razmišlja o vejah zahtevkov potegov kot o iterativnih pogovorih o predlagani spremembi, ki se končajo s skupno razliko, ki se uporablja z združevanjem.

To je pomembna razlika, saj se sprememba po navadi predlaga, preden se koda šteje za popolno, kar je pri popravkih po serijah, ki temeljijo na elektronski pošti, veliko manj pogosto. To omogoča prejšnji pogovor z vzdrževalci, da bi prišli do prave rešitve, ki je bolj prizadevanje skupnosti. Ko se z zahtevkom potega predlaga koda in vzdrževalci ali skupnost predlagajo spremembo, se serija popravkov ponavadi ne prenese na novo, temveč se razlika pošlje kot novo potrditev na veji, kar pomaga pri nadaljnjem pogovoru ob ohranjanju konteksta prejšnjega dela.

Na primer, če se vrnete in si ponovno ogledate sliko Končni zahtevek potega, boste opazili, da predlagatelj ni preklopil svoje potrditve in poslal novega zahtevka potega. Namesto tega je dodal nove potrditve in jih potisnil v obstoječo vejo. Tako lahko, če se v prihodnosti vrnete in si ogledate ta zahtevek potega, enostavno najdete celoten kontekst odločitev. Pritisk na gumb »Merge« na spletnem mestu namenoma ustvari potrditev združitve, ki se sklicuje na zahtevek potega, tako da se je enostavno vrniti in preučiti prvotni pogovor, če je to potrebno.

V koraku s povratnim tokom

Če vaš zahtevek potega zastara ali se na drugačen način ne združi gladko, ga boste želeli popraviti, da ga lahko vzdrževalec enostavno združi. GitHub bo to preizkusil za vas in vam sporočil na dnu vsakega zahtevka potega, ali je združevanje trivialno ali ne.

Zahtevek potega se ne združi gladko
Slika 96. Zahtevek potega se ne združi gladko

Če vidite kaj takega, kot je prikazano na sliki Zahtevek potega se ne združi gladko, boste želeli popraviti svojo vejo, da se obarva zeleno in vzdrževalcu ne bo treba opravljati dodatnega dela.

Imate dve glavni možnosti, da to storite. Lahko ponovno bazirate svojo vejo na vrhu ciljne veje (običajno veje master repozitorija, ki ste ga klonirali), ali pa ciljno vejo združite v svojo vejo.

Večina razvijalcev na GitHubu se odloči za slednjo možnost iz istih razlogov, ki smo jih pravkar obravnavali v prejšnjem odstavku. Pomembna je zgodovina in končno združevanje, zato ponovno baziranje ne prinaša veliko drugega kot nekoliko bolj čisto zgodovino, v zameno pa je veliko težje in bolj nagnjeno k napakam.

Če želite združiti ciljno vejo, da bo vaš zahtevek potega združljiv, dodate izvirni repozitorij kot nov oddaljeni vir, ga prenesete, združite glavno vejo tega repozitorija v svojo tematsko vejo, odpravite morebitne težave in ga nazadnje znova naložite v isto vejo, na kateri ste odprli zahtevek potega.

Na primer, recimo, da je prvotni avtor v primeru »tonychacon«, ki smo ga uporabljali prej, naredil spremembo, ki bi povzročila konflikt v zahtevku potega. Pojdimo skozi te korake.

$ git remote add upstream https://github.com/schacon/blink (1)

$ git fetch upstream (2)
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
Unpacking objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
From https://github.com/schacon/blink
 * [new branch]      master     -> upstream/master

$ git merge upstream/master (3)
Auto-merging blink.ino
CONFLICT (content): Merge conflict in blink.ino
Automatic merge failed; fix conflicts and then commit the result.

$ vim blink.ino (4)
$ git add blink.ino
$ git commit
[slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \
    into slower-blink

$ git push origin slow-blink (5)
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 682 bytes | 0 bytes/s, done.
Total 6 (delta 2), reused 0 (delta 0)
To https://github.com/tonychacon/blink
   ef4725c..3c8d735  slower-blink -> slow-blink
  1. Dodajte izvorni repozitorij kot daljavo poimenovano upstream.

  2. Pridobite najnovejše delo iz tega oddaljenega vira.

  3. Združite glavno vejo tega repozitorija v vašo tematsko vejo.

  4. Popravite konflikt, ki se je pojavil.

  5. Potisnite nazaj na isto tematsko vejo.

Ko to storite, bo zahtevek potega samodejno posodobljen in ponovno preverjen, če se gladko združi.

Zahtevek potega se sedaj združi gladko
Slika 97. Zahtevek potega se sedaj združi gladko

Ena od odličnih lastnosti Gita je, da to lahko storite neprekinjeno. Če imate zelo dolgotrajen projekt, lahko enostavno združujete s ciljno vejo znova in znova ter se ukvarjate le s konflikti, ki so se pojavili od zadnjega združevanja, kar olajša postopek.

Če absolutno želite preurediti vejo, da jo očistite, to zagotovo lahko storite, vendar močno priporočamo, da ne potisnete prisilno preko veje, na kateri je že odprt zahtevek potega. Če so jo druge osebe povlekle in nanjo dodale več dela, se srečate z vsemi težavami, ki so opisane v razdelku Nevarnosti ponovnega baziranja. Namesto tega potisnite ponovno bazirano vejo v novo vejo na GitHubu in odprite povsem nov zahtevek potega, ki se sklicuje na starega, nato pa zaprite izvirnega.

Reference

Vaše naslednje vprašanje je morda »Kako se sklicujem na stari zahtevek potega?«. Izkazalo se je, da obstaja veliko načinov za sklicevanje na druge stvari skoraj povsod, kjer lahko pišete na GitHubu.

Začnimo s tem, kako se sklicevati na drugi zahtevek potega ali težavo. Vse zahtevke potegov in težave imajo dodeljene številke in so edinstvene v projektu. Na primer, ne morete imeti zahtevka potega #3 in težave #3. Če se želite sklicevati na kateri koli zahtevek potega ali težavo od drugod, lahko preprosto vstavite #<številka> v kateri koli komentar ali opis. Lahko pa ste bolj natančni, če je težava ali zahtevek potega drugje; napišite uporabniško_ime#<num>, če se sklicujete na težavo ali zahtevek potega v razvejitvi repozitorija, v katerem ste, ali uporabniško_ime/repo#<num> za sklicevanje na kaj v drugem repozitoriju.

Poglejmo primer. Recimo, da smo preuredili vejo v prejšnjem primeru, ustvarili nov zahtevek potega in zdaj se želimo v novem sklicevati na stari zahtevek potega. Želimo se tudi sklicevati na težavo v razvejitvi repozitorija in težavo v popolnoma drugem projektu. Opis lahko izpolnite enako kot v razdelku Navzkrižno sklicevanje v zahtevku potega.

Navzkrižno sklicevanje v zahtevku potega
Slika 98. Navzkrižno sklicevanje v zahtevku potega

Ko bomo oddali ta zahtevek potega, bomo videli, da se bo vse to prikazalo tako kot na sliki Navzkrižne reference, upodobljene v zahtevku potega.

Navzkrižne reference, upodobljene v zahtevku potega
Slika 99. Navzkrižne reference, upodobljene v zahtevku potega

Opazite, da se je celoten URL na GitHubu, ki smo ga vnesli, skrajšal le na informacije, ki so potrebne.

Če Tony zdaj zapre prvotni zahtevek potega, lahko vidimo, da je GitHub avtomatično ustvaril sledilni dogodek v časovnici zahtevka potega, ker smo ga omenili v novem zahtevku. To pomeni, da lahko kdorkoli, ki obišče ta zahtevek potega, vidi, da je zaprt, in enostavno poveže nazaj s tistim, ki ga je nadomestil. Povezava bo videti nekako tako kot na sliki Povezava nazaj na nov zahtevek potega na zaprti časovnici zahtevka potega.

Povezava nazaj na nov zahtevek potega na zaprti časovnici zahtevka potega
Slika 100. Povezava nazaj na nov zahtevek potega na zaprti časovnici zahtevka potega

Poleg številk težav lahko na enak način kot referenčne oznake uporabimo tudi identifikatorje SHA-1 določenih potrditev. Pri tem je treba navesti celotnih 40 znakov identifikatorja SHA-1, vendar bo GitHub v komentarju takoj ustvaril povezavo do ustrezne potrditve. Kot pri težavah lahko tudi pri potrditvah v drugih razvejitvah ali repozitorijih uporabimo enak način referenciranja potrditev.

GitHub Flavored Markdown

Povezovanje na druge težave je samo začetek zanimivih stvari, ki jih lahko storite s skoraj vsakim besedilnim poljem na GitHubu. V opisih težav in zahtevkov potegov, komentarjih, komentarjih v kodi in še več, lahko uporabite, kar imenujemo »GitHub Flavored Markdown«. Markdown je podoben pisanju v navadnem besedilu, vendar je prikazan bogato.

Za primer, kako so lahko videti komentarji ali besedilo napisani z Markdownom, si oglejte sliko Primer GitHub Flavored Markdown, kot je napisan in upodobljen.

Primer GitHub Flavored Markdown, kot je napisan in upodobljen
Slika 101. Primer GitHub Flavored Markdown, kot je napisan in upodobljen

GitHub Flavored Markdown dodaja več stvari, ki jih lahko storite poleg osnovne sintakse Markdowna. Vse te dodatne funkcije so lahko resnično uporabne pri ustvarjanju koristnih komentarjev ali opisov težav in zahtevkov potegov.

Seznami opravil

Prva resnično uporabna funkcija specifična za GitHub Markdown, še posebej za uporabo pri zahtevkih potegov, je seznam opravil. Seznam opravil je seznam polj z oznakami za stvari, ki jih želite opraviti. Postavitev seznama v težavo ali zahtevek potega običajno pomeni, da želite te stvari opraviti, preden štejete element za dokončanega.

Seznam opravil lahko ustvarite tako:

- [X] Write the code
- [ ] Write all the tests
- [ ] Document the code

Če to vključimo v opis zahtevka potega ali težave, bomo videli, da se bo prikazal kot na Seznami opravil, upodobljeni v komentarju Markdown.

Seznami opravil, upodobljeni v komentarju Markdown
Slika 102. Seznami opravil, upodobljeni v komentarju Markdown

To se pogosto uporablja pri zahtevkih potegov, da bi označili, kaj vse bi radi dokončali na veji, preden bo zahtevek potega pripravljen za združevanje. Res odličen del je, da lahko preprosto kliknete polja z oznakami, da posodobite komentar — ne potrebujete urejanja Markdowna neposredno za označevanje opravil.

Poleg tega bo GitHub iskal sezname opravil v vaših težavah in zahtevkih potegov ter jih prikazal kot metapodatke na straneh, ki jih naštevajo. Na primer, če imate zahtevek potega z nalogami in si ogledate pregledno stran vseh zahtevkov potegov, lahko vidite, kako daleč je že opravljeno. To pomaga ljudem razbiti zahtevke potegov na podnaloge in drugim ljudem pomagati pri spremljanju napredka veje. Primer tega lahko vidite na sliki Povzetek seznama opravil na seznamu zahtevkov potegov.

Povzetek seznama opravil na seznamu zahtevkov potegov
Slika 103. Povzetek seznama opravil na seznamu zahtevkov potegov

Ti seznami so izjemno uporabni, ko odprete zahtevek potega zgodaj in ga uporabite za spremljanje svojega napredka pri izvedbi funkcionalnosti.

Delčki kode

V komentarje lahko dodate tudi delčke kode. To je še posebej uporabno, če želite nekaj predstaviti, kar bi lahko poskusili pred dejansko izvedbo kot potrditev na vaši veji. Pogosto se to uporablja tudi za dodajanje primerne kode o tem, kaj ne deluje, ali kaj bi lahko ta zahtevek potega implementiral.

Da dodate delček kode, ga morate »ograditi« v leve črtice.

```java
for(int i=0 ; i < 5 ; i++)
{
   System.out.println("i is : " + i);
}
```

Če dodate ime jezika, kot smo to storili z java, bo GitHub poskusil tudi poudariti sintakso delčka kode. V zgornjem primeru bo prikazan kot Primer upodobljene ograjene kode.

Primer upodobljene ograjene kode
Slika 104. Primer upodobljene ograjene kode

Citiranje

Če se odzivate na majhen del dolgega komentarja, lahko selektivno citirate iz drugega komentarja tako, da vrstice predhodno označite z znakom >. Dejansko je tako običajno in uporabno, da obstaja bližnjica na tipkovnici. Če v komentarju označite besedilo, na katero želite neposredno odgovoriti, in pritisnete tipko r, bo besedilo citirano v polju za komentarje.

Citati so videti nekako takole:

> Whether 'tis Nobler in the mind to suffer
> The Slings and Arrows of outrageous Fortune,

How big are these slings and in particular, these arrows?

Ko je komentar prikazan, bo videti nekako tako kot na sliki Prikazan primer citiranja.

Prikazan primer citiranja
Slika 105. Prikazan primer citiranja

Emodži

Končno lahko v svojih komentarjih uporabljate tudi emodžije. To se dejansko precej pogosto uporablja v komentarjih, ki jih vidite v mnogih težavah in zahtevkih potegov na GitHubu. Na GitHubu je na voljo tudi pomočnik za emodžije. Če vnesete komentar in začnete z znakom :, bo pomočnik za samodokončanje pomagal najti tisto, kar iščete.

Samodokončanje emodžijev v delovanju
Slika 106. Samodokončanje emodžijev v delovanju

Emodžiji imajo obliko :<ime>: kjerkoli v komentarju. Na primer, napišete lahko nekaj takega:

I :eyes: that :bug: and I :cold_sweat:.

:trophy: for :microscope: it.

:+1: and :sparkles: on this :ship:, it's :fire::poop:!

:clap::tada::panda_face:

Ko je prikazano, bi bilo videti nekako tako kot na sliki Komentiranje z veliko emodžiji.

Komentiranje z veliko emodžiji
Slika 107. Komentiranje z veliko emodžiji

Čeprav to ni izjemno koristno, vseeno doda element zabave in čustev v medij, v katerem je sicer težko izraziti čustva.

Opomba

Danes obstaja precej spletnih storitev, ki uporabljajo emodžije. Odličen pripomoček za hitro iskanje emodžijev, ki izražajo, kar želite povedati, lahko najdete na tej spletni strani:

Slike

To ni tehnično GitHub Flavored Markdown, vendar pa je izjemno koristno. Poleg dodajanja slikovnih povezav Markdown v komentarje, kar lahko zahteva iskanje in vdelavo URL-jev, vam GitHub omogoča, da slike povlečete in spustite v tekstovna področja, da jih vdelate.

Povlecite in spustite slike, da jih naložite in avtomatsko vdelate
Slika 108. Povlecite in spustite slike, da jih naložite in avtomatsko vdelate

Če pogledate na sliko Povlecite in spustite slike, da jih naložite in avtomatsko vdelate, lahko vidite majhen namig »Parsed as Markdown« nad besedilnim poljem. Če nanj kliknete, se vam bo prikazal celoten seznam vsega, kar lahko storite z Markdownom na GitHubu.

Poskrbite, da bo vaš javni repozitorij GitHub posodobljen

Ko enkrat razvejite repozitorij GitHub, bo vaš repozitorij (vaša »razvejitev«) obstajal neodvisno od izvirnega. Zlasti, ko izvorni repozitorij dobi nove potrditve, vas GitHub obvesti s sporočilom, kot je:

This branch is 5 commits behind progit:master.

Vendar pa vaš repozitorij na GitHubu ne bo nikoli samodejno posodobljen s strani GitHuba; to je nekaj, kar morate storiti sami. Na srečo je to zelo enostavno.

Ena možnost za to ne zahteva nobene konfiguracije. Na primer, če ste si različico naredili iz https://github.com/progit/progit2.git, lahko ohranite svojo vejo master posodobljeno na ta način:

$ git checkout master (1)
$ git pull https://github.com/progit/progit2.git (2)
$ git push origin master (3)
  1. Če ste na drugi veji, se vrnite na master.

  2. Pridobite spremembe iz https://github.com/progit/progit2.git in jih združite v master.

  3. Potisnite vašo vejo master na origin.

To deluje, vendar je malo dolgočasno vsakič preverjati URL pridobivanja. To lahko avtomatizirate z nekaj konfiguracije:

$ git remote add progit https://github.com/progit/progit2.git (1)
$ git fetch progit (2)
$ git branch --set-upstream-to=progit/master master (3)
$ git config --local remote.pushDefault origin (4)
  1. Dodajte izvorni repozitorij in mu dajte ime. Tukaj smo izbrali, da ga bomo imenovali progit.

  2. Pridobite referenco na veji master repozitorija progit.

  3. Nastavite vašo vejo master za prenašanje iz oddaljenega repozitorija progit.

  4. Določite privzeti repozitorij za potiskanje na origin.

Ko to storite, postane potek dela veliko preprostejši:

$ git checkout master (1)
$ git pull (2)
$ git push (3)
  1. Če ste bili na drugi veji, se vrnite na master.

  2. Prenesite spremembe iz progit in jih združite v master.

  3. Potisnite vašo vejo master na origin.

Ta pristop je lahko uporaben, vendar ima svoje pomanjkljivosti. Git bo tiho opravil to delo za vas, vendar vas ne bo opozoril, če naredite potrditev na master, povlečete spremembe iz progit in jih potisnete na origin — vse te operacije so veljavne s temi nastavitvami. Zato se morate izogibati neposrednemu potrjevanju v master, saj ta veja dejansko pripada povratnemu toku (angl. upstream) repozitorija.

scroll-to-top