-
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
5.2 Porazdeljeni Git - Prispevek k projektu
Prispevek k projektu
Glavna težava z opisovanjem, kako prispevati projektu, je, da obstaja veliko Å”tevilo spremenljivk, kako je to narejeno. Ker je Git zelo prilagodljiv, ljudje lahko in tudi res delajo skupaj na mnoge naÄine in problematiÄno je opisovati, kako bi morali prispevatiāāāvsak projekt je nekoliko drugaÄen. Nekatere vkljuÄene spremenljivke so Å”tevilo aktivnih ljudi, ki prispevajo, izbrani potek dela, vaÅ” dostop potrjevanja in po možnosti zunanja metoda prispevkov.
Prva spremenljivka je Å”tevilo aktivnih ljudi, ki prispevajoāāākoliko uporabnikov aktivno prispeva kodo temu projektu in kako pogosto? V mnogih primerih boste imeli dva ali tri razvijalce z nekaj potrditvami na dan ali po možnosti manj za projekte nekako v stanju mirovanja. Za veÄja podjetja ali projekte bi lahko Å”tevilo razvijalcev bilo v tisoÄih, s stotine ali tisoÄe potrditev, ki prihajajo vsak dan. To je pomembno, ker z veÄ in veÄ razvijalci naletite na veÄje težave, kako zagotavljati, da se vaÅ”a koda uporablja gladko oz. je enostavno združljiva. Spremembe, ki jih poÅ”ljete, lahko postanejo zastarele ali precej polomljene z delom, ki je bilo združeno, medtem ko ste delali, ali medtem ko vaÅ”e spremembe Äakajo na odobritev ali uporabo. Kako lahko obdržite svojo kodo konsistentno posodobljeno in vaÅ”e potrditve veljavne?
Naslednja spremenljivka je potek dela, ki je v uporabi za projekt. Je centraliziran, kjer ima vsak razvijalec enak dostop pisanja v glavno linijo kode? Ali ima projekt vzdrževalca ali integracijskega upravitelja, ki preveri vse popravke? So vsi popravki strokovno pregledani in odobreni? Ali ste vkljuÄeni v ta proces? Ali je sistem poroÄnika na mestu in ali jim morate najprej poslati svoje delo?
Naslednja spremenljivka je vaÅ” dostop potrditev. Potek dela, ki je zahtevan za prispevek k projektu, je veliko bolj drugaÄen, Äe imate dostop pisanja k projektu, kot Äe ga nimate. Äe nimate dostopa za pisanje, kako ima projekt raje, da sprejme prispevano delo? Ali ima sploh pravilnik? Koliko dela prispevate na doloÄen Äas? Kako pogosto prispevate?
Vsa ta vpraÅ”anja lahko vplivajo, kako efektivno prispevati projektu in katere poteke dela imate raje, oziroma so vam na voljo. Pokrili bomo vidike vsakega od teh v seriji primerov uporabe in se premaknili od enostavnega do bolj kompleksnega; morali bi biti sposobni skonstruirati doloÄen potek dela, ki ga potrebujete v praksi iz teh primerov.
Smernice potrjevanja
Preden zaÄnemo gledati doloÄene primere uporabe, je tu hitro obvestilo o sporoÄilih potrditev.
Imeti dobre smernice za ustvarjanje potrditev in se jih držati, naredi delo z Gitom in sodelovanjem z ostalimi veliko enostavnejŔe.
Projekt Git ponuja dokument, ki zaÄrta Å”tevilo dobrih nasvetov za ustvarjanje potrditev, iz katerih se poÅ”ljejo popravkiāāāto lahko preberete v izvorni kodi Git v datoteki Documentation/SubmittingPatches
.
Kot prvo, ne želite poslati kakrŔnih koli napak praznih znakov.
Git ponuja enostaven naÄin, da to preveriteāāāpreden potrdite, poženite git diff --check
, ki identificira vse možne napake praznih znakov in vam jih izpiŔe.

git diff --check
Äe poženete ta ukaz preden potrdite, lahko poveste, ali ste tik pred tem, da potrdite tudi težave s praznimi znaki, ki lahko nagajajo ostalim razvijalcem.
Naslednje poskusite narediti vsako potrditev kot logiÄen loÄen skupek sprememb.
Äe lahko, poskusite narediti svoje spremembe prebavljiveāāāne kodirajte cel vikend na petih razliÄnih težavah in nato poÅ”ljite vse kot eno masovno potrditev v ponedeljek.
Tudi Äe ne naredite potrditve med koncem tedna, uporabite podroÄje priprave v ponedeljek, da se loÄi vaÅ”e delo v vsaj eno potrditev na težavo z uporabnim sporoÄilom na potrditev.
Äe nekatere spremembe spremenijo isto datoteko, poskusite uporabiti git add --patch
za delno pripravo datoteke (podrobno pokrito v razdelku Interaktivno pripravljanje).
Posnetek projekta pri vrhu veje je identiÄen, Äe naredite eno ali pa pet potrditev, dokler so vse spremembe dodane na neki toÄki, torej poskusite narediti stvari enostavne za svoje kolege razvijalce, ko bodo morali pregledati vaÅ”e spremembe.
Ta pristop naredi enostavnejÅ”e tudi vleÄenje ali povrnitev ene izmed skupka sprememb, Äe to kasneje potrebujete. Razdelek Prepisovanje zgodovine opisuje Å”tevilo uporabnih trikov Git za prepisovanje zgodovine in interaktivno dajanje datotek v podroÄje pripraveāāāuporabite ta orodja, da vam pomagajo izdelati Äisto in razumljivo zgodovino, preden poÅ”ljete delo nekomu drugemu.
Zadnja stvar za pomnjenje je sporoÄilo potrditve. Navaditi se ustvarjati kakovostna sporoÄila potrditev naredi uporabo in sodelovanje z Gitom veliko enostavnejÅ”e. Kot sploÅ”no pravilo bi se vaÅ”a sporoÄila morala zaÄeti z eno vrstico, ki ni veÄja od 50 znakov in jedrnato opisuje skupek sprememb ter nato ji sledi prazna vrstica, ki ji sledi podrobnejÅ”a razlaga. Projekt Git zahteva, da bolj podrobna razlaga vkljuÄuje vaÅ”o motivacijo za spremembe in kontrast njene implementacije s prejÅ”njim obnaÅ”anjemāāāto je tudi dobra smernica za sledenje. NapiÅ”ite svoja sporoÄila potrditev v velelniku: Ā»Popravi hroÅ”ÄĀ« in ne Ā»Popravljen hroÅ”ÄĀ« ali Ā»To popravi hroÅ”ÄĀ«. Tu lahko sledite tej predlogi, ki smo jo malenkost prilagodili po tej, ki jo je prvotno napisal Tim Pope:
Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase will confuse you if you run the
two together.
Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug." This convention matches up with commit messages generated
by commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, followed by a
single space, with blank lines in between, but conventions vary here
- Use a hanging indent
Äe vsa vaÅ”a sporoÄila potrditev sledijo temu modelu, so stvari veliko enostavnejÅ”e za vas in razvijalce, s katerimi delate.
Projekt Git ima dobro oblikovana sporoÄila potrditevāāāposkusite tam pognati git log --no-merges
, da vidite, kakŔna je lepo oblikovana zgodovina potrditev projekta.
Opomba
|
Naredite, kot pravimo, in ne kot to mi poÄnemo.
VeÄina primerov v tej knjigi zaradi kratkosti nima lepo oblikovanih sporoÄil, kot je ta; namesto tega, uporabljamo možnost Na kratko, naredite, kot pravimo, in ne kot to mi poÄnemo. |
Zasebna majhna ekipa
NajenostavnejÅ”a nastavitev, na katero boste verjetno naleteli, je zasebni projekt z enim ali dvema razvijalcema. Ā»ZasebniĀ« v tem kontekstu pomeni zaprto kodoāāāni dostopna za zunanji svet. Vi in ostali razvijalci imate vsi dostop potiskanja v repozitorij.
V tem okolju lahko sledite poteku dela, ki je podoben, kakor ste morda delali, ko ste uporabljali Subversion ali drug centraliziran sistem.
Å e vedno dobite prednosti stvari, kot so potrjevanje brez povezave in prostrano enostavnejÅ”e razvejanje in združevanje, vendar potek dela je lahko zelo podoben; glavna razlika je, da se združevanje zgodi na strani odjemalca namesto na strežniku v Äasu potrditve.
Poglejmo, kako je lahko videti, ko dva razvijalca zaÄneta delati skupaj z deljenim repozitorijem.
Prvi razvijalec, John, klonira repozitorij, naredi spremembe in jih potrdi lokalno.
SporoÄila protokola so bila v teh primerih zamenjana s ā¦ā
, da se nekako skrajŔajo.
# John's Machine
$ git clone john@githost:simplegit.git
Cloning into 'simplegit'...
...
$ cd simplegit/
$ vim lib/simplegit.rb
$ git commit -am 'Remove invalid default value'
[master 738ee87] Remove invalid default value
1 files changed, 1 insertions(+), 1 deletions(-)
Druga razvijalka, Jessica, naredi isto stvarāāāklonira repozitorij in potrdi spremembo:
# Jessica's Machine
$ git clone jessica@githost:simplegit.git
Cloning into 'simplegit'...
...
$ cd simplegit/
$ vim TODO
$ git commit -am 'Add reset task'
[master fbff5bc] Add reset task
1 files changed, 1 insertions(+), 0 deletions(-)
Sedaj Jessica potisne njeno delo na strežnik:
# Jessica's Machine
$ git push origin master
...
To jessica@githost:simplegit.git
1edee6b..fbff5bc master -> master
Zadnja vrstica izhoda zgoraj prikazuje uporabno sporoÄilo o vrnitvi iz operacije potiska.
Osnovni format je <oldref>..<newref> fromref ā toref
, kjer oldref
pomeni staro referenco, newref
pomeni novo referenco, fromref
je ime lokalne reference, ki jo potiskamo, in toref
je ime oddaljene reference, ki jo posodabljamo.
Podoben izhod boste videli spodaj v razpravah, zato bo osnovna ideja o pomenu pomagala pri razumevanju razliÄnih stanj repozitorijev.
VeÄ podrobnosti najdete v dokumentaciji za git-push.
Äe nadaljujemo s tem primerom, kmalu zatem John naredi nekaj sprememb, jih potrdi v svojem lokalnem repozitoriju in jih poskuÅ”a potisniti na isti strežnik:
# John's Machine
$ git push origin master
To john@githost:simplegit.git
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'john@githost:simplegit.git'
V tem primeru Johnov potisk ni uspeÅ”en, ker je vmes potisnila Jessica njene spremembe. To je posebej pomembno razumeti, Äe ste vajeni Subversiona, ker boste opazili, da dva razvijalca nista uredila iste datoteke. Äeprav Subversion naredi to združevanje avtomatiÄno na strežniku, Äe se urejajo razliÄne datoteke, morate z Gitom najprej združiti potrditve lokalno. Z drugimi besedami, John mora najprej prenesti zgornje spremembe Jessice in jih združiti v svoj lokalni repozitorij, preden bo smel potisniti.
Kot prvi korak John prenese delo Jessice (to samo prenese zgornje delo Jessice in ga Ŕe ne združi v Johnovo delo):
$ git fetch origin
...
From john@githost:simplegit
+ 049d078...fbff5bc master -> origin/master
Na tej toÄki je Johnov lokalni repozitorij videti nekako takole:

Sedaj lahko John združi Jessicino delo, ki ga je prenesel v svoje lokalno delo:
$ git merge origin/master
Merge made by the 'recursive' strategy.
TODO | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Dokler gre to lokalno združevanje gladko, bo Johnova posodobljena zgodovina sedaj videti nekako takole:

origin/master
Sedaj lahko John testira to novo kodo, da zagotovi, da nobeno delo Jessice ne vpliva na nobeno njegovo in dokler poteka vse ustrezno, lahko potisne novo združeno delo na strežnik:
$ git push origin master
...
To john@githost:simplegit.git
fbff5bc..72bbc59 master -> master
Na koncu je Johnova zgodovina potrditev videti nekako takole:

origin
Vmes je Jessica ustvarila novo tematsko vejo imenovano issue54
in na tej veji naredila tri potrditve.
Ni pa Ŕe prenesla Johnovih sprememb, zato je njena zgodovina potrditev videti nekako takole:

Nenadoma Jessica izve, da je John potisnil nekaj novega dela na strežnik, in želi ga pogledati, torej lahko prenese vso novo vsebino iz strežnika, ki je Ŕe nima:
# Jessica's Machine
$ git fetch origin
...
From jessica@githost:simplegit
fbff5bc..72bbc59 master -> origin/master
To povleÄe delo, ki ga je vmes John potisnil. Zgodovina Jessice je sedaj videti takole:

Jessica misli, da je njena tematska veja pripravljena, vendar želi vedeti, kateri del prenesenega Johnovega dela mora združiti v njeno delo, da lahko potisne.
Požene git log
, da ugotovi:
$ git log --no-merges issue54..origin/master
commit 738ee872852dfaa9d6634e0dea7a324040193016
Author: John Smith <jsmith@example.com>
Date: Fri May 29 16:01:27 2009 -0700
Remove invalid default value
Sintaksa issue54..origin/master
je dnevniŔki filter, ki vpraŔa Git, da prikaže samo seznam potrditev, ki so na slednji veji (v tem primeru origin/master
) in ki niso na prvi veji (v tem primeru issue54
).
Skozi to sintakso bomo Ŕli podrobneje v Obsegi potrditev.
Iz zgornjega izpisa lahko vidimo, da je ena potrditev, ki jo je naredil John, in je Jessica ni združila v njeno lokalno delo.
Äe ona združi origin/master
, je to ena potrditev, ki bo spremenila njeno lokalno delo.
Sedaj lahko Jessica združi njeno tematsko delo v njeno vejo master
, združi, Johnovo delo (origin/master
) v njeno vejo master
in nato potisne nazaj na strežnik.
Najprej, (ko je potrdila vso delo na svoji tematski veji issue54
), preklopi nazaj na njeno vejo master
v pripravi, da integrira vso to delo:
$ git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
Jessica lahko najprej združi origin/master
ali pa issue54
āāāobe sta iz povratnega toka, torej vrstni red ni pomemben.
Zadnji posnetek bi moral biti identiÄen ne glede na vrstni red, ki ga izbere, samo zgodovina bo nekoliko drugaÄna.
Najprej, izbere združiti vejo issue54
:
$ git merge issue54
Updating fbff5bc..4af4298
Fast forward
README | 1 +
lib/simplegit.rb | 6 +++++-
2 files changed, 6 insertions(+), 1 deletions(-)
Ne pride do nobenih problemov; kot lahko vidite, je Ŕlo za enostaven fast-forward.
Sedaj Jessica zakljuÄi proces lokalnega združevanja in združi prej preneseno delo Johna, ki Äaka v veji origin/master
:
$ git merge origin/master
Auto-merging lib/simplegit.rb
Merge made by the 'recursive' strategy.
lib/simplegit.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Vse se gladko združi in zgodovina Jessice je sedaj videti takole:

Sedaj je origin/master
dosegljiv iz Jessicine veje master
, da lahko uspeÅ”no potisne (ob predpostavki, da John vmes ni ponovno potisnil Å”e veÄ sprememb):
$ git push origin master
...
To jessica@githost:simplegit.git
72bbc59..8059c15 master -> master
Vsak razvijalec je naredil nekaj potrditev in uspeŔno združil delo drug drugega.

To je eden najenostavnejŔih potekov dela.
Nekaj Äasa delate, (v sploÅ”nem na tematski veji), in združite to delo v vaÅ”o vejo master
, ko je pripravljeno za integracijo.
Ko želite deliti to delo, prenesete in združite vaŔo vejo master
iz origin/master
, Äe se je kaj spremenilo, in na koncu potisnite na vejo master
na strežniku.
SploŔno zaporedje je nekaj takega:

Zasebne upravljane ekipe
V tem naslednjem scenariju, boste pogledali vloge sodelavcev v veÄji zasebni skupini. NauÄili se boste, kako delati v okolju, kjer sodelujejo manjÅ”e skupine na lastnostih, in nato so ti prispevki na osnovi ekip integrirani s strani druge stranke.
Recimo, da John in Jessica delata skupaj na eni lastnosti (recimo featureA
), medtem ko Jessica in tretja razvijalka Josie delata na drugi (recimo featureB
).
V tem primeru podjetje uporablja tip poteka dela upravitelja integracije, kjer je delo posameznih skupin integrirano samo od doloÄenih inženirjev in veja master
glavnega repozitorija je lahko posodobljena samo s strani teh inženirjev.
V tem scenariju je vse delo narejeno na vejah na osnovi ekip in kasneje povleÄene skupaj s strani povezovalcev.
Sledimo poteku dela Jessice, kakor dela na dveh njenih lastnostih, vzporedno sodeluje z dvema razliÄnima razvijalcema v tem okolju.
Predpostavimo, da že ima svoj repozitorij kloniran in se odloÄi delati najprej na lastnosti featureA
.
Ustvari novo vejo za lastnost in naredi nekaj dela na njej:
# Jessica's Machine
$ git checkout -b featureA
Switched to a new branch 'featureA'
$ vim lib/simplegit.rb
$ git commit -am 'Add limit to log function'
[featureA 3300904] Add limit to log function
1 files changed, 1 insertions(+), 1 deletions(-)
Na tej toÄki morate deliti nekaj dela z Johnom, torej potisne njene potrditve veje featureA
na strežnik.
Jessica nima dostopa potiskanja na vejo master
āāāto imajo samo povezovalciāāātorej mora potisniti na drugo vejo, da lahko sodeluje z Johnom:
$ git push -u origin featureA
...
To jessica@githost:simplegit.git
* [new branch] featureA -> featureA
Jessica sporoÄi Johnu po e-poÅ”ti, da je potisnila nekaj dela v vejo imenovano featureA
, in on lahko to sedaj pogleda.
Medtem ko Äaka na povratne informacije od Johna, se Jessica odloÄi zaÄeti delati na lastnosti featureB
z Josie.
Da zaÄne, ustvari novo vejo lastnosti, ki je osnovana na strežniÅ”ki veji master
:
# Jessica's Machine
$ git fetch origin
$ git checkout -b featureB origin/master
Switched to a new branch 'featureB'
Sedaj, Jessica naredi nekaj potrditev na veji featureB
:
$ vim lib/simplegit.rb
$ git commit -am 'Make ls-tree function recursive'
[featureB e5b0fdc] Make ls-tree function recursive
1 files changed, 1 insertions(+), 1 deletions(-)
$ vim lib/simplegit.rb
$ git commit -am 'Add ls-files'
[featureB 8512791] Add ls-files
1 files changed, 5 insertions(+), 0 deletions(-)
Jessicin repozitorij je videti sedaj takole:

Pripravljena je potisniti njeno delo, vendar dobi e-poŔto od Josie, da je veja featureB
z nekaj zaÄetnega dela na njej že potisnjena na strežnik kot featureBee
.
Jessica mora najprej združiti te spremembe v njeno lastno, preden lahko potisne svoje delo na strežnik.
Jessica najprej prenese spremembe Josie z git fetch
:
$ git fetch origin
...
From jessica@githost:simplegit
* [new branch] featureBee -> origin/featureBee
Ob predpostavki, da je Jessica Å”e vedno na svoji izvleÄeni veji featureB
, lahko sedaj združi delo Josie v to vejo z git merge
:
$ git merge origin/featureBee
Auto-merging lib/simplegit.rb
Merge made by the 'recursive' strategy.
lib/simplegit.rb | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
V tem trenutku Jessica želi vse združeno delo featureB
potisniti nazaj na strežnik, vendar noÄe preprosto potisniti svoje veje featureB
.
Ker je Josie že zaÄela z zgornjo vejo featureBee
, želi Jessica potisniti na to vejo, kar stori s:
$ git push -u origin featureB:featureBee
...
To jessica@githost:simplegit.git
fba9af8..cd685d1 featureB -> featureBee
To se imenuje refspec.
Glejte razdelek Refspec za bolj podrobno diskusijo refspec Gita in razliÄnih stvari, ki jih lahko naredite z njimi.
Bodite pozorni tudi na zastavico -u
; to je okrajŔava za --set-upstream
, ki nastavi veje za enostavnejÅ”e kasnejÅ”e potiskanje in vleÄenje.
Nenadoma Jessica prejme e-poÅ”to od Johna, ki ji sporoÄi, da je potisnil nekaj sprememb na vejo featureA
, na kateri sodelujeta, in jo prosi, naj si jih ogleda.
Jessica ponovno zažene preprost ukaz git fetch
, da prenese vse nove vsebine s strežnika, vkljuÄno (seveda) z Johnovim najnovejÅ”im delom:
$ git fetch origin
...
From jessica@githost:simplegit
3300904..aad881d featureA -> origin/featureA
Jessica lahko prikaže dnevnik Johnovega novega dela s primerjavo vsebine na novo prenesene veje featureA
s svojo lokalno kopijo iste veje:
$ git log featureA..origin/featureA
commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
Author: John Smith <jsmith@example.com>
Date: Fri May 29 19:57:33 2009 -0700
Increase log output to 30 from 25
Äe je Jessici vÅ”eÄ, kar vidi, lahko združi novo delo Johna v njeno lokalno vejo featureA
:
$ git checkout featureA
Switched to branch 'featureA'
$ git merge origin/featureA
Updating 3300904..aad881d
Fast forward
lib/simplegit.rb | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
Nazadnje bi Jessica lahko želela narediti nekaj manjŔih sprememb na vsem tem združenem delu, zato je prosta, da naredi te spremembe, jih potrdi v svoji lokalni veji featureA
in potisne konÄni rezultat nazaj na strežnik:
$ git commit -am 'Add small tweak to merged content'
[featureA 774b3ed] Add small tweak to merged content
1 files changed, 1 insertions(+), 1 deletions(-)
$ git push
...
To jessica@githost:simplegit.git
3300904..774b3ed featureA -> featureA
Zgodovina potrditev Jessice je sedaj videti nekako takole:

V nekem trenutku Jessica, Josie in John obvestijo povezovalce, da sta veji featureA
in featureBee
na strežniku pripravljeni za integracijo v glavno vejo.
Ko povezovalci združijo ti veji v glavno vejo, bo prenos prinesel novo potrditev združitve, zaradi Äesar bo zgodovina videti takole:

Zaradi te zmožnosti mnoge skupine preklopijo na Git, da imajo veÄ ekip, ki delajo vzporedno in združujejo na razliÄnih vrsticah dela kasneje v procesu. Zmožnost manjÅ”ih podskupin ekipe, da sodelujejo preko oddaljenih vej brez potrebe po vkljuÄevanju ali oviri celotne ekipe, je velika prednost Gita. Zaporedje poteka dela, ki ste ga tu videli, je nekaj takega:

Razvejan javni projekt
Prispevki k javnim projektom so nekoliko drugaÄni. Ker nimate dovoljenja neposredno posodobiti veje na projektu, morate nekako dati delo vzdrževalcem na drug naÄin. Prvi primer opisuje prispevke preko razvejanja na gostiteljih Git, ki podpirajo enostavno razvejanje. Mnoge strani gostiteljev to podpirajo (vkljuÄno z GitHub, BitBucket, Google Code, repo.or.cz in ostalimi) in mnogi vzdrževalci projektov priÄakujejo ta stil prispevkov. Naslednji razdelek se ukvarja s projekti, ki imajo raje sprejeti prispevke popravkov preko e-poÅ”te.
Najprej boste verjetno želeli klonirati glavni repozitorij, ustvariti tematsko vejo za programski popravek ali serijo popravkov, ki jih planirate prispevati in narediti delo tam. Zaporedje je videti v osnovi takole:
$ git clone <url>
$ cd project
$ git checkout -b featureA
... work ...
$ git commit
... work ...
$ git commit
Opomba
|
Lahko boste želeli uporabiti |
Ko je delo vaÅ”e veje konÄano in ste pripravljeni prispevati nazaj vzdrževalcem, pojdite na prvotno stran projekta in kliknite na gumb Ā»ForkĀ«, kar bo ustvarilo vaÅ”o lastno zapisljivo razvejitev projekta.
Nato morate dodati ta novi URL repozitorija kot novo daljavo svojega lokalnega repozitorija; v tem primeru ga imenujmo myfork
:
$ git remote add myfork <url>
Nato morate potisniti svoje novo delo v ta repozitorij.
NajenostavnejŔe je potisniti tematsko vejo, na kateri delate, na vaŔ razvejan repozitorij namesto združevanja v vaŔo vejo master
in potiskanja tega navzgor.
Razlog je, da Äe delo ni sprejeto, ali so izbrane samo najboljÅ”e spremembe (angl. cherry picking), vam ni treba previti nazaj vaÅ”e veje master
(operacija Gita cherry-pick
je pokrita bolj podrobno v Poteki dela ponovnega baziranja in izbire najboljŔega).
Äe vzdrževalci združijo, ponovno bazirajo ali izberejo samo najboljÅ”e spremembe vaÅ”ega dela, ga boste tako ali tako eventualno povlekli nazaj iz njihovega repozitorija:
V kateremkoli primeru lahko potisnete svoje delo na naslednji naÄin:
$ git push -u myfork featureA
Ko je bilo vaŔe delo potisnjeno na vaŔo razvejitev, morate obvestiti vzdrževalce prvotnega projekta, da imate delo, ki ga želite, da ga združijo.
To je pogostokrat imenovano zahtevek potega in tak zahtevek obiÄajno generirate preko spletne straniāāāGitHub ima svoj lastni mehanizem zahtevkov potega, ki jih bomo obravnavali v GitHubāāāali pa poženete ukaz git request-pull
in poÅ”ljete vzdrževalcu projekta dani izpis roÄno po e-poÅ”ti.
Ukaz git request-pull
vzame osnovno vejo, v katero želite povleÄi svojo tematsko vejo, in URL repozitorija Git, iz katerega želite, da ga povleÄejo, ter izpiÅ”e povzetek vseh sprememb, za katere želite, da se povleÄejo.
Na primer, Äe Jessica želi poslati Johnu zahtevek potega in je konÄala dve potrditvi na tematski veji, ki jo je ravnokar potisnila, lahko požene tole:
$ git request-pull origin/master myfork
The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
Jessica Smith (1):
Create new function
are available in the git repository at:
https://githost/simplegit.git featureA
Jessica Smith (2):
Add limit to log function
Increase log output to 30 from 25
lib/simplegit.rb | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
Ta izpis se lahko poÅ”lje vzdrževalcuāāāpove jim, od kod je delo razvejano, povzame potrditve in pove, od kod povleÄi to delo.
Na projektu, za katerega niste vzdrževalec, je v sploŔnem enostavnejŔe imeti vejo, kot je master
, ki vedno sledi origin/master
, in narediti vaÅ”e delo v tematskih vejah, ki jih lahko enostavno zavržete, Äe so zavrnjene.
Delovne teme, izolirane v tematske veje, so vam tudi enostavnejÅ”e, da ponovno bazirate vaÅ”e delo, Äe se je konica glavnega repozitorija vmes premaknila in vaÅ”ih potrditev ni veÄ mogoÄe gladko uporabiti.
Na primer, Äe želite poslati drugo temo dela projekta, ne nadaljujte delo na tematski veji, ki ste jo ravnokar potisnili, zaÄnite raje znova iz veje master
glavnega repozitorija:
$ git checkout -b featureB origin/master
... work ...
$ git commit
$ git push myfork featureB
$ git request-pull origin/master myfork
... email generated request pull to maintainer ...
$ git fetch origin
Sedaj je vsaka od vaÅ”ih tem vsebovana znotraj silosaāāāpodobno kot Äakalna vrsta popravkaāāāki jo lahko prepiÅ”ete in spremenite, brez da se teme med seboj vmeÅ”avajo ali so soodvisne druga od druge:

featureB
Recimo, da je vzdrževalec projekta povlekel veliko ostalih popravkov in poskusil vaÅ”o prvo vejo, vendar se ne združuje veÄ gladko.
V tem primeru lahko to vejo poskusite ponovno bazirati na vrh origin/master
, reŔite konflikte za vzdrževalca in nato ponovno poŔljete svoje spremembe:
$ git checkout featureA
$ git rebase origin/master
$ git push -f myfork featureA
To prepiŔe vaŔo zgodovino, da je sedaj videti kot na sliki Zgodovina potrditev po delu featureA
.

featureA
Ker ste vejo ponovno bazirali, morate doloÄiti -f
za vaÅ” ukaz potiskanja, da lahko zamenjate vejo featureA
na strežniku s potrditvijo, ki ni njen potomec.
Alternativa bi bila potisniti to novo delo na drugo vejo na strežniku (mogoÄe imenovano featureAv2
).
Poglejmo en bolj verjeten scenarij: vzdrževalec je pogledal delo v vaÅ”i drugi veji in mu je zasnova vÅ”eÄ, vendar bi rad, da spremenite podrobnost implementacije.
To priložnost boste tudi vzeli, da premaknete delo, da bo osnovano na trenutni veji projekta master
.
ZaÄnete novo vejo, ki je osnovana na trenutni veji origin/master
, tam stisnite spremembe featureB
, reŔite kakrŔnekoli konflikte, naredite implementacijo sprememb in nato to potisnite kot novo vejo:
$ git checkout -b featureBv2 origin/master
$ git merge --squash featureB
... change implementation ...
$ git commit
$ git push myfork featureBv2
Možnost --squash
vzame vso delo na združeni veji in jih stisne v en skupek sprememb, ki ustvari stanje repozitorija, kakor da bi se zgodilo resniÄno združevanje, ne da dejansko naredi potrditev združitve.
To pomeni, da bo vaÅ”a prihodnja potrditev imela samo eno nadrejeno in vam omogoÄa uvedbo vseh sprememb iz druge veje ter nato naredite veÄ sprememb pred snemanjem nove potrditve.
Uporabna je lahko tudi možnost --no-commit
, ki zakasni potrditev združitve v primeru privzetega procesa združevanja.
Sedaj lahko poÅ”ljete vzdrževalcu sporoÄilo, da ste naredili zahtevane spremembe in da te spremembe lahko najdejo v vaÅ”i veji featureBv2
.

featureBv2
Javni projekt preko e-poŔte
Mnogi projekti imajo ustaljene postopke za sprejemanje popravkovāāāpreveriti boste morali doloÄena pravila za vsak projekt, ker se razlikujejo. Odkar je na voljo nekaj starejÅ”ih, veÄjih projektov, ki sprejemajo popravke preko razvijalskega e-poÅ”tnega seznama, bomo Å”li sedaj skozi primer tega.
Potek dela je podoben prejÅ”njemu primeru uporabeāāāustvarite tematske veje za vsake serije popravka, na katerih delate. Razlika je, kako jih poÅ”ljete projektu. Namesto razvejanja projekta in potiskanja v svojo lastno zapisljivo razliÄico generirate e-poÅ”tno razliÄico za vsako od serij potrditev in jih poÅ”ljete po e-poÅ”ti razvijalskemu e-poÅ”tnemu seznamu:
$ git checkout -b topicA
... work ...
$ git commit
... work ...
$ git commit
Sedaj imate dve potrditvi, ki ju želite poslati na e-poŔtni seznam.
Uporabili boste git format-patch
, da generirate mbox oblikovane datoteke, ki jih lahko poÅ”ljete preko e-poÅ”te na seznamāāāvsako potrditev pretvori v sporoÄilo e-poÅ”te s prvo vrstico sporoÄila potrditve kot zadevo in preostanek sporoÄila ter programski popravek, ki ga potrditev predstavlja kot telo.
Dobra stvar pri tem je, da uporaba popravka generiranega iz e-poŔte s format-patch
ustrezno ohrani vse informacije potrditve.
$ git format-patch -M origin/master
0001-add-limit-to-log-function.patch
0002-increase-log-output-to-30-from-25.patch
Ukaz format-patch
izpiŔe imena datotek popravka, ki ga ustvari.
Preklop -M
pove Gitu, da iÅ”Äe preimenovanja.
Datoteke so na koncu videti takole:
$ cat 0001-add-limit-to-log-function.patch
From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
From: Jessica Smith <jessica@example.com>
Date: Sun, 6 Apr 2008 10:17:23 -0700
Subject: [PATCH 1/2] Add limit to log function
Limit log functionality to the first 20
---
lib/simplegit.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/simplegit.rb b/lib/simplegit.rb
index 76f47bc..f9815f1 100644
--- a/lib/simplegit.rb
+++ b/lib/simplegit.rb
@@ -14,7 +14,7 @@ class SimpleGit
end
def log(treeish = 'master')
- command("git log #{treeish}")
+ command("git log -n 20 #{treeish}")
end
def ls_tree(treeish = 'master')
--
2.1.0
Lahko tudi uredite te datoteke popravka, da dodate veÄ informacij za seznam e-poÅ”te, za katere ne želite, da se prikažejo v sporoÄilu potrditve.
Äe dodate besedilo med vrstico ---
in zaÄetek popravka (vrstica diff --git
), potem ga razvijalci lahko preberejo, vendar proces popravka vsebino izkljuÄuje.
Da to poŔljete po e-poŔti na e-poŔtni seznam, lahko prilepite datoteko v vaŔ e-poŔtni program, ali pa poŔljete preko programa ukazne vrstice.
Lepljenje teksta pogostokrat povzroÄa težave oblikovanja, posebej s Ā»pametnejÅ”imiĀ« odjemalci, ki ne ohranjajo ustrezno novih vrstic in ostalih praznih znakov.
Na sreÄo, Git ponuja orodje, ki vam pomaga poslati ustrezno oblikovane popravke preko IMAP, kar je za vas lahko enostavnejÅ”e.
Prikazali bomo, kako poslati programski popravek preko Gmaila, kar je e-poŔtni agent, ki ga najbolje poznamo; preberete lahko podrobna navodila za Ŕtevilo poŔtnih programov na koncu zgoraj omenjene datoteke Documentation/SubmittingPatches
v izvorni kodi Git.
Najprej morate nastaviti razdelek imap v vaŔi datoteki ~/.gitconfig
.
Nastavite lahko vsako vrednost loÄeno s serijo ukazov git config
ali pa jih dodate roÄno, vendar na koncu bi vaÅ”a nastavitvena datoteka morala biti videti nekako takole:
[imap]
folder = "[Gmail]/Drafts"
host = imaps://imap.gmail.com
user = user@gmail.com
pass = YX]8g76G_2^sFbd
port = 993
sslverify = false
Äe vaÅ” strežnik IMAP ne uporablja SSL, zadnji dve vrstici verjetno nista potrebni in vrednost gostitelja bo imap://
namesto imaps://
.
Ko je to nastavljeno, lahko uporabite git imap-send
, da dodate serijo popravkov v mapo Drafts doloÄenega strežnika IMAP:
$ cat *.patch |git imap-send
Resolving imap.gmail.com... ok
Connecting to [74.125.142.109]:993... ok
Logging in...
sending 2 messages
100% (2/2) done
V tem trenutku bi morali imeti dostop do vaŔe mape osnutkov (angl. Drafts), lahko spremenite polje »To« na seznam e-poŔte, na katerega poŔiljate programski popravek, opcijsko »CC« za vzdrževalca ali osebo, odgovorno za ta razdelek, in lahko ga poŔljete.
Programski popravek lahko poŔljete tudi preko strežnika SMTP.
Kot prej, lahko nastavite vsako vrednost loÄeno s serijo ukazov git config
, ali pa jih dodate roÄno v razdelek sendemail vaÅ”e datoteke ~/.gitconfig
:
[sendemail]
smtpencryption = tls
smtpserver = smtp.gmail.com
smtpuser = user@gmail.com
smtpserverport = 587
Ko je to narejeno, lahko uporabite git send-email
, da poŔljete svoje popravke:
$ git send-email *.patch
0001-add-limit-to-log-function.patch
0002-increase-log-output-to-30-from-25.patch
Who should the emails appear to be from? [Jessica Smith <jessica@example.com>]
Emails will be sent from: Jessica Smith <jessica@example.com>
Who should the emails be sent to? jessica@example.com
Message-ID to be used as In-Reply-To for the first email? y
Nato Git izpljune kopico informacij dnevnika, kar je videti nekako takole za vsak programski popravek, ki ga poŔiljate:
(mbox) Adding cc: Jessica Smith <jessica@example.com> from
\line 'From: Jessica Smith <jessica@example.com>'
OK. Log says:
Sendmail: /usr/sbin/sendmail -i jessica@example.com
From: Jessica Smith <jessica@example.com>
To: jessica@example.com
Subject: [PATCH 1/2] Add limit to log function
Date: Sat, 30 May 2009 13:29:15 -0700
Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com>
X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty
In-Reply-To: <y>
References: <y>
Result: OK
Namig
|
Za pomoÄ, kako nastaviti vaÅ” sistem in e-poÅ”to, veÄ nasvetov in trikov ter peskovnik za poÅ”iljanje preizkusnega popravka preko e-poÅ”te, obiÅ”Äite git-send-email.io. |
Povzetek
V tem razdelku smo obravnavali veÄ potekov dela in razpravljali o razlikah med delom v majhni ekipi na zaprtem projektu in prispevku k velikemu javnemu projektu. Sedaj veste, kako pred potrditvijo preveriti napake praznih znakov in napisati znate odliÄno sporoÄilo potrditve. NauÄili ste se, kako oblikovati popravke in kako jih poÅ”ljete po e-poÅ”ti na seznam razvijalcev. Razpravljali smo tudi o združevanju pri razliÄnih potekih dela. Zdaj ste dobro pripravljeni za sodelovanje na katerem koli projektu.
V nadaljevanju boste videli, kako deluje druga plat medalje: vzdrževanje projekta Git. NauÄili se boste, kako biti dobronamerni diktator ali integracijski upravitelj.