4.1 Git sur la servilo - La Protokoloj
Ĉe tiu punkto, Vi devus esti kapabla fari la plejparto de la tago al tago taskoj por kiuj vi estos uzanta Git. Tamen, por fari ajnan kunlaboron en Git, vi bezonos havi fora Git-deponejo.
Kvankam vi povas teknike puŝi ŝanĝojn kaj tiri ŝanĝoj de individuoj
'deponejoj, farante tuj kiam estas malinstigita ĉar vi povas sufiĉe
facile konfuzi kion ili laboras sur se vi ne estas zorgema.
Plue, vi volas vian kunlaborantoj por povi aliri la deponejo eĉ se via
komputilo estas offline - havi pli fidinda komuna deponejo estas ofte
utila.
Sekve, la preferata metodo por kunlabori kun iu estas starigi intera
deponejo ke vi ambaŭ havas aliron al, kaj puŝi por kaj tiri el tio.
Kuranta Git servilo estas sufiĉe simpla. Unue vi elektu kiu protokoloj volas vian servilon por komuniki kun. La unua sekcio de tiu ĉapitro kovras la disponeblaj protokoloj kaj la avantaĝoj kaj malavantaĝoj de ĉiu. La sekva sekcioj klarigos iuj tipaj aranĝoj uzante tiujn protokolojn kaj kiel akiri vian servilon kurante kun ili. Lasta, ni iros super kelkaj gastigita ebloj, se vi ne ĝenas retprovizanton via kodo en aliulaj servilo kaj ne volas iri tra la hassle de alĝustigo kaj subteni vian propran servilon.
Se vi havas neniun intereson en kurado via propra servilo, vi povas salti al la lasta sekcio de la ĉapitro vidi iujn eblojn por starigi gastigita konton kaj tiam movi sur al la sekvanta ĉapitro, kie ni diskutos la diversajn ins kaj outs de laborado en distribuita fonto kontrolo medio.
Al fora enciklopedio estas ĝenerale nuda enciklopedio - la Git-deponejo kiu havas neniun labordosierujon. Ĉar la deponejo estas uzata nur kiel kunlaborado punkto, ne estas kialo por havi instantánea Taksis surdiske; ĝi estas nur la Git datumoj. En la plej simpla terminoj, nuda deponejo estas la enhavo de via projekto
Se vi havas dividita muntita dosiersistemo, tiam vi povas kloni, puŝi por kaj tiri el loka dosiero-bazita deponejo. Kloni deponejo tiel aŭ aldoni kiel fora al ekzistanta projekto, uzu la padon al la deponejo kiel la retadreso. Ekzemple, kloni loka deponejo, vi povas kuri proksimume tia:
Aldoni lokan deponejon al ekzistantan Git projekto, vi povas kuri proksimume tia:
Tiu estas ankaŭ bela eblo por rapide kaptante laboro de aliulaj laborista enciklopedio. Se vi kaj co-laboristo estas laboranta sur la sama projekto kaj ili volas ke vi kontrolu ion, kuri komandon kiel
Estas grave mencii ke ĉi tio ne estas nepre la plej rapida eblo se vi uzas komunan monto ia. Loka deponejo estas rapida nur se vi havas rapidan aliron al la datumoj. A-deponejo sur NFS estas ofte malrapidaj ol la deponejo super SSH sur la sama servilo, permesante Git kuri ekstere lokaj diskoj sur ĉiu sistemo.
Fine, ĉi tiu protokolo ne protektas la deponejo kontraŭ akcidenta damaĝo. Ĉiu uzanto havas plenan ŝelo aliro al la "fora" dosierujo, kaj estas nenio malhelpante ilin de ŝanĝanta aŭ foriganta interna Git dosierojn kaj korupti la deponejo.
Ĝi verŝajne fariĝis la plej populara maniero uzi Git nun, ĉar ĝi povas esti instalita al ambaŭ servi anonime kiel la
Fakte, por servoj kiel GitHub, la URL vi uzu por vidi la deponejo rete (ekzemple, " https://github.com/schacon/simplegit ") estas la sama URL vi povas uzi kloni kaj, se vi havas aliron , puŝi super.
Ĝenerale vi ĉu elekti kuri legita / skribi Smart HTTP servilo aŭ simple havi la dosierojn alirebla kiel nur legado en la Muta maniero. Ĝi estas malofte kuras miksaĵo de la du servoj.
La simpleco de havi solan URL por ĉiuj tipoj de aliro kaj havanta la servilo prompto nur kiam autenticación bezonas faras aferojn tre facila por la uzanto fino. Povi autenticar kun uzantnomo kaj pasvorto estas ankaŭ granda avantaĝo super SSH, ekde uzantoj ne devas generi SSH klavoj loke kaj alŝuti siajn publika ŝlosilo al la servilo antaŭ povi interagi kun ĝi. Por malpli kompleksaj uzantoj, aŭ uzantoj en sistemoj kie SSH estas malpli komuna, tio estas granda avantaĝo en usabilidad. Ĝi estas ankaŭ tre rapida kaj efika protokolo, simila al la SSH unu.
Vi povas ankaŭ servi vian deponejoj nur legado super HTTPS, kiu signifas vin povas ĉifri la enhavon transporto; aŭ vi povas iri tiel ege kiel fari la klientoj uzas specifajn subskribis SSL atestilojn.
Alia bela afero estas ke HTTP / S estas tia komune uzataj protokoloj korporacia firewalls ofte starigita permesi trafikon tra tiuj havenoj.
Se vi uzas HTTP por aŭtentikigita puŝante, disponigante viajn akreditaĵojn estas kelkfoje pli komplika ol uzante klavojn super SSH. Ekzistas tamen pluraj credencial caching iloj vi povas uzi, inkluzive Keychain aliro sur OSX kaj Credencial Direktisto en Windows, fari tiun belan sendolora. Legi Credencial Stokado vidi kiel agordi sekura HTTP pasvorton caching sur via sistemo.
Por kloni Git-deponejo super SSH, vi povas specifi ssh: // URL tiel:
Kuranta Git servilo estas sufiĉe simpla. Unue vi elektu kiu protokoloj volas vian servilon por komuniki kun. La unua sekcio de tiu ĉapitro kovras la disponeblaj protokoloj kaj la avantaĝoj kaj malavantaĝoj de ĉiu. La sekva sekcioj klarigos iuj tipaj aranĝoj uzante tiujn protokolojn kaj kiel akiri vian servilon kurante kun ili. Lasta, ni iros super kelkaj gastigita ebloj, se vi ne ĝenas retprovizanton via kodo en aliulaj servilo kaj ne volas iri tra la hassle de alĝustigo kaj subteni vian propran servilon.
Se vi havas neniun intereson en kurado via propra servilo, vi povas salti al la lasta sekcio de la ĉapitro vidi iujn eblojn por starigi gastigita konton kaj tiam movi sur al la sekvanta ĉapitro, kie ni diskutos la diversajn ins kaj outs de laborado en distribuita fonto kontrolo medio.
Al fora enciklopedio estas ĝenerale nuda enciklopedio - la Git-deponejo kiu havas neniun labordosierujon. Ĉar la deponejo estas uzata nur kiel kunlaborado punkto, ne estas kialo por havi instantánea Taksis surdiske; ĝi estas nur la Git datumoj. En la plej simpla terminoj, nuda deponejo estas la enhavo de via projekto
.git dosierujo kaj nenio alia. Protokoloj
Git povas uzi kvar gravaj protokoloj translokigi datumon: Loka, HTTP, Secure Shell (SSH) kaj git. Tie ni diskutos kion ili estas kaj en kion bazaj cirkonstancoj vi volus (aŭ ne volas) uzi ilin.lokaj Protokolo
La plej baza estas la Loka protokolon, en kiu la fora deponejo estas en alia dosierujo en disko. Ĉi estas ofte uzata se ĉiuj en via teamo havas aliron al komuna dosiersistemo kiel NFS monton nek en la malpli verŝajna kazo ke ĉiuj ensalutas al la sama komputilo. La lasta devus ne esti idealo, ĉar ĉiuj viaj kodo enciklopedio okazojn loĝus sur la sama komputilo, farante katastrofa perdo multe pli verŝajna.Se vi havas dividita muntita dosiersistemo, tiam vi povas kloni, puŝi por kaj tiri el loka dosiero-bazita deponejo. Kloni deponejo tiel aŭ aldoni kiel fora al ekzistanta projekto, uzu la padon al la deponejo kiel la retadreso. Ekzemple, kloni loka deponejo, vi povas kuri proksimume tia:
$ Git clone /opt/git/project.git
Aŭ vi povas fari tion: $ Git clone dosiero: ///opt/git/project.git
Git operacias iomete malsame se vi eksplicite specifi file:// komence de la URL. Se vi nur specifi la vojon, Git provas uzi hardlinks aŭ rekte kopii la dosierojn bezonas. Se vi specifas file://
, Git maldungas la procezoj kiuj ĝi kutime uzas por transferir datumoj
super reto kiu estas ĝenerale multe malpli efika metodo de transdonado
la datumoj. La ĉefa kialo por specifi la file://
prefikso estas se vi volas puran kopion de la deponejo kun fremda
referencojn aŭ objektoj lasitaj ekstere - ĝenerale post importado de
alia versio kontrolo sistemo aŭ ion similan (vidu Git internals por bontenado taskoj) . Ni uzos la normalan vojon tien ĉar faranta estas preskaŭ ĉiam pli rapide. Aldoni lokan deponejon al ekzistantan Git projekto, vi povas kuri proksimume tia:
$ Git fora aldonu local_proj /opt/git/project.git
Tiam, vi povas premi por kaj tiri el tiu fora kvazaux vi faranta sur reto. la Pros
La avantaĝoj de dosiero bazita deponejoj estas ke ili estas simplaj kaj ili uzas ekzistantajn dosiero permesojn kaj reto aliro. Se vi jam havas dividitaj dosiersistemo kiu via tuta teamo havas aliron, starigante deponejo estas tre facila. Vi algluita la nudajn enciklopedio kopion ie ĉiuj dividis aliro al ekbruligis la legado / skribo permesojn kiel vi farus por iu alia komuna dosierujo. Ni diskuti kiel eksporti nuda enciklopedio kopion tiucele en Getting Git sur Servilo .Tiu estas ankaŭ bela eblo por rapide kaptante laboro de aliulaj laborista enciklopedio. Se vi kaj co-laboristo estas laboranta sur la sama projekto kaj ili volas ke vi kontrolu ion, kuri komandon kiel
git pull /home/john/project estas ofte pli facile ol ilin pelas al fora servilo kaj vi detruis. la trompoj
La contras de ĉi tiu metodo estas kiu dividis aliro estas ĝenerale pli malfacile starigi kaj atingi de multoblaj lokoj ol baza reto aliro. Se vi volas puŝi de via tekkomputilo kiam vi estas hejme, vi devas munti la fora disko, kiu povas esti malfacila kaj malrapida kompare kun reto-bazita aliro.Estas grave mencii ke ĉi tio ne estas nepre la plej rapida eblo se vi uzas komunan monto ia. Loka deponejo estas rapida nur se vi havas rapidan aliron al la datumoj. A-deponejo sur NFS estas ofte malrapidaj ol la deponejo super SSH sur la sama servilo, permesante Git kuri ekstere lokaj diskoj sur ĉiu sistemo.
Fine, ĉi tiu protokolo ne protektas la deponejo kontraŭ akcidenta damaĝo. Ĉiu uzanto havas plenan ŝelo aliro al la "fora" dosierujo, kaj estas nenio malhelpante ilin de ŝanĝanta aŭ foriganta interna Git dosierojn kaj korupti la deponejo.
La HTTP- Protokoloj
Git povas komuniki super HTTP en du malsamaj manieroj. Antaŭ Git 1.6.6 ekzistis nur unu maniero povus fari tiu kiu estis tre simpla kaj ĝenerale nur legado. En versio 1.6.6 nova, inteligenta protokolo estis enkondukita kiu implikis Git povi inteligente negoci transporto de datumoj en maniero simila al kiel ĝi faras super SSH. En la lastaj jaroj, ĉi tiu nova protokolo HTTP fariĝis tre populara ĉar ĝi estas pli simpla por la uzanto kaj inteligenta pri kiel komunikas. La pli nova versio estas ofte referita al kiel la "Lerta" protokolo HTTP kaj la malnovaj maniero kiel "Muta" HTTP. Ni kovras la pli nova "smart" protokolo HTTP unua.smart HTTP
La "inteligentaj" protokolo HTTP operacias tre simile al la SSH aŭ Git protokoloj sed alveturas normo HTTP / S havenoj kaj povas uzi diversajn HTTP aŭtentokontrolo mekanismoj, signifa ĝi estas ofte pli simpla al la uzanto ol io kiel SSH, ĉar vi povas uzi aĵojn kiel uzantonomo / pasvorton baza aŭtentokontrolo anstataŭ devi instali SSH klavoj.Ĝi verŝajne fariĝis la plej populara maniero uzi Git nun, ĉar ĝi povas esti instalita al ambaŭ servi anonime kiel la
git:// protokolo, kaj povas ankaŭ esti puŝita super kun autenticación kaj ĉifrado kiel la SSH protokolo. Anstataŭ devi agordi malsamajn URLoj por tiuj aferoj, Vi povas nun uzi solan URL por ambaŭ.
Se vi provos puŝi la deponejo postulas aŭtentokontrolo (kiu normale
devus), la servilo povas suflori por salutnomon kaj pasvorton. La sama iras por legado aliro. Fakte, por servoj kiel GitHub, la URL vi uzu por vidi la deponejo rete (ekzemple, " https://github.com/schacon/simplegit ") estas la sama URL vi povas uzi kloni kaj, se vi havas aliron , puŝi super.
muta HTTP
Se la servanto ne respondas kun Git HTTP inteligenta servado, la Git kliento provos replegarse al la simpla "muta" protokolo HTTP. La Muta protokolo atendas la nuda Git-deponejo por utili kiel normala dosierojn el la servilo. La beleco de la Muta HTTP- protokolon estas la simpleco de opcio ĝin. Esence, ĉiuj vi devas fari estas meti nuda Git-deponejo sub via HTTP dokumenton radiko kaj starigis specifapost-update hoko, kaj vi faris (Vidi Git Hokoj ). En tiu punkto, ĉiu kiu povas aliri la TTT-servilo sub kiun pasxos la deponejo povas kloni via deponejo. Permesi legrajtojn por via deponejo super HTTP, fari ion kiel jene: Tio estas ĉio. La$cd/ var / www / htdocs /$Git clone --bare / vojo / al / git_project gitproject.git$cdgitproject.git$Mv hokoj / post-update.sample hokoj / post-ĝisdatigo$Chmod a + x hokoj / post-ĝisdatigo
post-update hoko kiu venas kun Git defaŭlte kuras la taŭga komando ( git update-server-info ) fari HTTP kolektadon kaj klonado laboro konvene. Tiu komando estas kuri kiam vin puŝi al tiu enciklopedio (super SSH eble); do aliaj homoj povas kloni tra ion kiel $ Git clone https://example.com/gitproject.git
En ĉi tiu aparta kazo, ni uzas la /var/www/htdocs pado kiu estas komuna por Apache aranĝoj, sed vi povas uzi iun statika retservilo - simple meti la nudajn deponejo en ĝia pado. La Git datumoj utilas kiel baza statikaj dosieroj (vidu Git internals por detaloj pri precize kiel ĝi estas servita). Ĝenerale vi ĉu elekti kuri legita / skribi Smart HTTP servilo aŭ simple havi la dosierojn alirebla kiel nur legado en la Muta maniero. Ĝi estas malofte kuras miksaĵo de la du servoj.
la Pros
Ni koncentros sur la avantaĝoj de la Smart versio de la HTTP-protokolo.La simpleco de havi solan URL por ĉiuj tipoj de aliro kaj havanta la servilo prompto nur kiam autenticación bezonas faras aferojn tre facila por la uzanto fino. Povi autenticar kun uzantnomo kaj pasvorto estas ankaŭ granda avantaĝo super SSH, ekde uzantoj ne devas generi SSH klavoj loke kaj alŝuti siajn publika ŝlosilo al la servilo antaŭ povi interagi kun ĝi. Por malpli kompleksaj uzantoj, aŭ uzantoj en sistemoj kie SSH estas malpli komuna, tio estas granda avantaĝo en usabilidad. Ĝi estas ankaŭ tre rapida kaj efika protokolo, simila al la SSH unu.
Vi povas ankaŭ servi vian deponejoj nur legado super HTTPS, kiu signifas vin povas ĉifri la enhavon transporto; aŭ vi povas iri tiel ege kiel fari la klientoj uzas specifajn subskribis SSL atestilojn.
Alia bela afero estas ke HTTP / S estas tia komune uzataj protokoloj korporacia firewalls ofte starigita permesi trafikon tra tiuj havenoj.
la trompoj
GIT sur HTTP / S povas esti iom pli malfacila starigi kompare al SSH sur iuj serviloj. Krom tiu, estas tre malgranda avantaĝo ke aliaj protokoloj havas super la "Smart" protokolo HTTP por servanta Git.Se vi uzas HTTP por aŭtentikigita puŝante, disponigante viajn akreditaĵojn estas kelkfoje pli komplika ol uzante klavojn super SSH. Ekzistas tamen pluraj credencial caching iloj vi povas uzi, inkluzive Keychain aliro sur OSX kaj Credencial Direktisto en Windows, fari tiun belan sendolora. Legi Credencial Stokado vidi kiel agordi sekura HTTP pasvorton caching sur via sistemo.
La SSH protokolo
Komuna transporto protokolo por Git kiam mem-gastiganta estas super SSH. Tiu estas ĉar SSH aliro al serviloj jam instalita en plej lokoj - kaj se ne, ĝi estas facile fari. SSH estas ankaŭ aŭtentikigita reto protokolo; kaj ĉar ĝi estas ĉiea, ĝi estas ĝenerale facila starigi kaj uzi.Por kloni Git-deponejo super SSH, vi povas specifi ssh: // URL tiel:
$ Git clone ssh: //user@server/project.git
Aŭ vi povas uzi la pli mallonga scp-simila sintakso al la SSH protokolo: $ Git clone uzanto @ servilo: project.git
Vi povas ankaŭ ne specifi uzanto kaj Git supozas la uzanto vi salutis kiel. la Pros
La avantaĝoj de uzi SSH estas multaj. Unua, SSH estas relative facila starigi - SSH demonoj estas ordinaraj, multaj reto administrantoj havas sperton kun ili, kaj da VIN distribuoj estas starigita kun ili aŭ havi ilojn por administri ilin. Sekva, aliro super SSH estas sekura - ĉiuj transporto de datumoj estas ĉifrita kaj legalizita. Lasta, kiel la HTTP / S, Git kaj Lokaj protokoloj, SSH estas efika, farante la datumojn kiel kompakta kiel ebla antaŭ kopii ĝin.la trompoj
La negativa aspekto de SSH estas ke vi ne povas servi anonima aliro de via deponejo super ĝi. Homoj devas havi aliron al via maŝino super SSH aliri ĝin, eĉ en nurlega kapablo, kiu ne faras SSH aliro faciliga malfermi fonto projektoj. Se vi uzas nur ene via kompania reto, SSH povas esti la nura protokolo vi devas trakti. Se vi volas permesi anonimajn nurlega aliro al via projektoj kaj ankaŭ volas uzi SSH, vi devos agordi SSH por vi premi super sed io alia por aliaj por preni super.La Git Protokolo
Sekva estas la Git-protokolo. Tiu estas speciala demono kiu venas pakita kun Git; aŭskultas sur diligenta haveno (9418) kiu provizas servon similan al la SSH protokolo, sed kun absolute neniu aŭtentokontrolo. En ordo por deponejo esti servita super la Git protokolo, vi devas krei lagit-daemon-export-ok dosiero - la demono ne servos deponejo sen tiu dosiero en ĝi - sed krom tio ekzistas neniu sekureco. Ĉu la Git-deponejo estas disponebla por ĉiuj kloni aŭ ne. Tio signifas ke estas ĝenerale ne puŝas super tiu protokolo. Vi povas ebligi puŝo aliro;
sed donita la manko de autenticación, se vi ŝaltas puŝo aliro, iu sur
la interreto kiu trovas viajn projekto URL povus puŝi al via projekto. Sufiĉas diri ke ĉi tiu estas malofta. la Pros
La Git protokolo estas ofte la plej rapida reto tradona protokolo disponeblas. Se vi servanta multajn trafiko por publika projekto aŭ servanta tre grandan projekton kiu ne postulas uzulon por legrajtojn, estas probable ke vi volas starigi Git demono servi vian projekton. Ĝi uzas la samajn datumojn-transigo mekanismo kiel la SSH protokolo sed sen la ĉifrado kaj aŭtentokontrolo superkape.la trompoj
La malavantaĝo de la Git protokolo estas la manko de autenticación. Ĝi estas ĝenerale nedezirinda pro la Git protokolo esti la nura aliro al via projekto. Ĝenerale, vi duo per SSH aux HTTPS aliro por la malmultaj desarrolladores kiu havas puŝo (skribi) aliro kaj havas ĉiuj aliajn uzogit:// por legi nur aliro. Ĝi estas ankaŭ probable la plej malfacila protokolo starigi. Ĝi devas kuri lian propran demono, kiu postulas xinetd agordo aŭ simile, kio ne ĉiam promeni en la parko. Ĝi ankaŭ postulas fajroŝirmilo aliro al haveno 9418, kiu ne estas normo haveno kiu kompania firewalls ĉiam permesas. Malantaŭ granda kompania firewalls, tiu obskura haveno estas kutime blokita. 
Nenhum comentário:
Postar um comentário