-
1. Začetek
- 1.1 O nadzoru različic
- 1.2 Kratka zgodovina Gita
- 1.3 Kaj je Git?
- 1.4 Ukazna vrstica
- 1.5 Namestitev Gita
- 1.6 Prva nastavitev Gita
- 1.7 Pridobivanje pomoči
- 1.8 Povzetek
-
2. Osnove Git
- 2.1 Pridobivanje repozitorija Git
- 2.2 Snemanje sprememb v repozitorij
- 2.3 Pregled zgodovine potrditev
- 2.4 Razveljavljanje stvari
- 2.5 Delo z daljavami
- 2.6 Označevanje
- 2.7 Aliasi Git
- 2.8 Povzetek
-
3. Veje Git
- 3.1 Veje na kratko
- 3.2 Osnove vej in združevanja
- 3.3 Upravljanje vej
- 3.4 Poteki dela z vejami
- 3.5 Oddaljene veje
- 3.6 Ponovno baziranje
- 3.7 Povzetek
-
4. Git na strežniku
- 4.1 Protokoli
- 4.2 Pridobitev Gita na strežniku
- 4.3 Generiranje vaših javnih ključev SSH
- 4.4 Nastavitev strežnika
- 4.5 Prikriti proces Git
- 4.6 Pametni HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti gostovanja pri tretjih ponudnikih
- 4.10 Povzetek
-
5. Porazdeljeni Git
- 5.1 Porazdeljeni poteki dela
- 5.2 Prispevek k projektu
- 5.3 Vzdrževanje projekta
- 5.4 Povzetek
-
6. GitHub
-
7. Orodja Git
- 7.1 Izbira revizije
- 7.2 Interaktivno pripravljanje
- 7.3 Shranjevanje na varno (angl. stashing) in čiščenje
- 7.4 Podpisovanje vašega dela
- 7.5 Iskanje
- 7.6 Prepisovanje zgodovine
- 7.7 Demistifikacija ponastavitve
- 7.8 Napredno združevanje
- 7.9 Rerere
- 7.10 Razhroščevanje z Gitom
- 7.11 Podmoduli
- 7.12 Povezovanje v pakete
- 7.13 Zamenjava
- 7.14 Shramba poverilnic
- 7.15 Povzetek
-
8. Prilagoditev Gita
- 8.1 Konfiguracija Git
- 8.2 Atributi Git
- 8.3 Kljuke Git
- 8.4 Primer pravilnika, ki ga uveljavlja Git
- 8.5 Povzetek
-
9. Git in ostali sistemi
- 9.1 Git kot odjemalec
- 9.2 Migracija na Git
- 9.3 Povzetek
-
10. Notranjost Gita
- 10.1 Napeljava in keramika
- 10.2 Objekti Git
- 10.3 Reference Git
- 10.4 Packfiles (datoteke zmanjšanih podatkov)
- 10.5 Refspec
- 10.6 Protokoli prenosa
- 10.7 Vzdrževanje in obnovitev podatkov
- 10.8 Spremenljivke okolja
- 10.9 Povzetek
-
A1. Dodatek A: Git v drugih okoljih
- A1.1 Grafični vmesniki
- A1.2 Git v Visual Studio
- A1.3 Git v Visual Studio Code
- A1.4 Git v IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git v Sublime Text
- A1.6 Git v Bashu
- A1.7 Git v Zsh
- A1.8 Git v Powershellu
- A1.9 Povzetek
-
A2. Dodatek B: Vdelava Gita v vašo aplikacijo
- A2.1 Git v ukazni vrstici
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Dodatek C: Ukazi Git
- A3.1 Nastavitev in konfiguracija
- A3.2 Pridobivanje in ustvarjanje projektov
- A3.3 Osnove posnetkov
- A3.4 Veje in združevanje
- A3.5 Deljenje in posodabljanje projektov
- A3.6 Pregled in primerjava
- A3.7 Razhroščevanje
- A3.8 Popravljanje
- A3.9 E-pošta
- A3.10 Zunanji sistemi
- A3.11 Administracija
- A3.12 Orodja za sisteme napeljave
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.
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:
-
Razvejite projekt.
-
Ustvarite tematsko vejo iz veje
master
. -
Naredite nekaj potrditev za izboljšanje projekta.
-
To vejo potisnite v svoj projekt GitHub.
-
Odprite zahtevek potega na GitHubu.
-
Razpravljajte in po potrebi še naprej delajte potrditve.
-
Lastnik projekta združi ali zapre zahtevek potega.
-
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.
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
-
Klonirajte svojo razvejitev projekta lokalno.
-
Ustvarite opisno tematsko vejo.
-
Naredite spremembo v kodi.
-
Preverite, da je sprememba dobra.
-
Potrdite spremembo v tematski veji.
-
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.
Č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.
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.
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:
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.
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.
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 |
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.
Č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
-
Dodajte izvorni repozitorij kot daljavo poimenovano
upstream
. -
Pridobite najnovejše delo iz tega oddaljenega vira.
-
Združite glavno vejo tega repozitorija v vašo tematsko vejo.
-
Popravite konflikt, ki se je pojavil.
-
Potisnite nazaj na isto tematsko vejo.
Ko to storite, bo zahtevek potega samodejno posodobljen in ponovno preverjen, če se gladko združi.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Č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.
Č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)
-
Če ste na drugi veji, se vrnite na
master
. -
Pridobite spremembe iz
https://github.com/progit/progit2.git
in jih združite vmaster
. -
Potisnite vašo vejo
master
naorigin
.
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)
-
Dodajte izvorni repozitorij in mu dajte ime. Tukaj smo izbrali, da ga bomo imenovali
progit
. -
Pridobite referenco na veji
master
repozitorijaprogit
. -
Nastavite vašo vejo
master
za prenašanje iz oddaljenega repozitorijaprogit
. -
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)
-
Če ste bili na drugi veji, se vrnite na
master
. -
Prenesite spremembe iz
progit
in jih združite vmaster
. -
Potisnite vašo vejo
master
naorigin
.
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.